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DETACHABLE  SUMMARY Page  S-l 


The  research  described  herein  covers  a part  of  the  "design"  phase  of  a 
computer  based  dynamic  system  to  Test  and  Evaluate  Local  Operating  Systems, 
referred  to  as  TELOS.  This  study  was  performed  by  Research  Triangle 
Institute  and  was  sponsored  by  the  Defense  Civil  Preparedness  Agency  (DCPA) 
under  Contract  No.  DCPA01-77-C-0238. 

The  long  term  goal  of  this  DCPA  effort  is  to  develop  a computer-based 
dynamic  simulation  capable  of  supporting  the  TELOS  both  generically,  wherein 
component  research,  training  and  national  assessment  roles  are  pursued,  and, 
specifically,  wherein  planning  and  training  roles  give  direction  to  local 
systems.  The  purpose  of  the  current  RTI  effort  was  to  integrate  all 
components  of  TELOS  under  an  executive  control;  to  convert  TELOS  to  operate 
on  the  UNIVAC  1100/10  at  DCPACC;  and  to  demonstrate  the  ability  of  TELOS  to 
simulate  a local  Civil  Defense  operating  system. 

A system  overview  is  contained  in  this  report  with  a brief  description 
of  all  components.  The  simulation  is  summarized  as  follows:  the  system 
functions  under  a set  of  controls  which  govern  an  attack  module  that 
generates  overpressure,  thermal,  and  nuclear  radiation  levels  at  various 
points  over  the  entire  local  area.  The  local  area  is  described  by  a data 
base  that  can  be  varied  by  control  inputs.  The  Area  Damage  Summary  (ADS) 
module  relates  the  resources  to  the  environment  levels  and  describes  the 
resulting  damage.  The  local  countermeasures  module  (LEMOS)  responds  to 
problems  derived  from  plans  or  an  examination  of  resource  damage  after  each 
attack  event.  Through  various  countermeasures,  LEMOS  either  protects 
resources  from  subsequent  damage  or  expends  resources  to  relieve  the 
distress  resulting  from  the  weapon  effects.  In  either  case,  the  location 
and  state  of  local  resources  are  altered.  An  iterative  process  between  the 
countermeasures  and  damage  assessment  modules  conducts  operations  through  a 
number  of  time  periods  dictated  by  system  control.  An  evaluation  module 
analyzes  the  outputs  from  both  ADS  and  LEMOS  with  respect  to  the  particular 
role  of  TELOS.  On  the  basis  of  this  evaluation,  controls  for  further  data 
generation  are  determined  and  a new  cycle  begins. 

The  overall  TELOS  system  is  still  incomplete  although  many  of  its 
missing  elements  are  well  defined.  The  primary  activity  during  the  current 
contract  was  concerned  with  testing  and  conversion  of  the  LEMOS  elements. 

All  existing  modules  and  submodels  have  been  converted  to  operate  on  the 
UNIVAC  1100/10  computer  at  Olney,  Maryland.  That  is,  the  same  multi-area 
test  runs  have  been  successfully  made  on  that  machine.  The  files  developed 
before  conversion  were  used  to  confirm  that  the  conversion  to  the  UNIVAC 
1100/10  was  complete.  Deficiencies  of  the  system  are  identified  and 
described  as  a basis  for  an  overall  plan  for  completing  the  TELOS  system. 

Based  on  the  test  and  conversion  activities  performed,  RTI  recommends 
that  extensions  to  TELOS,  including  a communication  submodel  and  an 
evaluation  module,  be  started  immediately,  that  detailed  documentation  of 
all  modules  be  initiated,  and  that  further  development  effort  be  conducted 
using  the  UNIVAC  1100/10  remote  terminal  facilities  at  DCPACC.  In  addition, 
RTI  recommends  that  the  program  plan  outlined  in  this  report  become  the 
basis  for  a fully  validated  DCPA  program  to  reach  the  long  term  goal  stated 
in  paragraph  2 above. 
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The  research  described  herein  covers  a part  of  the  "design"  phase  of  a 
computer  based  dynamic  system  to  Test  and  Evaluate  Local  Operating  Systems, 
referred  to  as  TELOS. 

This  work  was  sponsored  by  the  Defense  Civil  Preparedness  Agency  (DCPA) 
under  Contract  No.  DCPA01-77-C-0238  dated  September  27,  1977,  and  as  amended 
subsequently.  Principal  activities  during  the  current  period  of  performance 
were  to  complete  the  program  tests  and  conversions  described  in  Section  III 
and  Appendix  B.  The  balance  of  this  report  is  intended  to  update  the  status 
of  the  TELOS  system  development  program. 

The  authors  express  their  indebtedness  to  Mr.  James  Jacobs  of  DCPA  for 
his  guidance  during  the  study.  The  authors  also  express  their  appreciation 
to  Mr.  Edward  L.  Hill  and  to  others  in  the  Research  Triangle  Institute  who 
supported  this  research.  A special  note  of  appreciation  is  given  to  Mr. 
Thomas  W.  Della  who  during  the  course  of  this  work  made  a significant 
contribution  to  the  system  integration  effort  and  whose  untimely  death 
represented  a very  real  loss  to  his  associates  and  to  this  project. 


I 


ABSTRACT 


Page  iii 


A computer  based  simulation  designed  to  Test  and  Evaluate  Local 
Operating  Systems  (TELOS)  has  been  under  development  for  some  time.  During 
the  past  year,  RTI  has  continued  to  refine  the  modules  and  overall  main 
program  of  the  Local  Emergency  Operating  System  (LEMOS)  and  to  convert  them 
to  the  UNI  VAC  1100/10  operating  system  at  DCPACC.  The  main  accomplishment 
during  the  contract  period  has  been  the  test  runs  using  a small  two-area 
data  base  to  check  the  adequacy  of  the  procedures  to  process  the  master  file 
that  is  to  be  produced  by  the  Area  Damage  Summary  (ADS)  System.  At  present, 
ADS  does  not  produce  the  records  in  the  master  file  which  describe  the 
damage  states  of  Civil  Defense  resources.  Therefore,  the  test  data  does  not 
confirm  the  interface  between  the  damage  assessment  submodel  (ADS)  and  the 
countermeasures  module  of  LEMOS.  While  the  test  data  proved  useful  in 
verifying  the  essential  interfaces  between  modules  (file,  record  formats  and 
data  elements),  it  did  not  prove  to  be  adequate  to  verify  the  accuracy  of 
these  data.  Extensive  testing  will  be  required  in  a subsequent  effort  to 
demonstrate  the  overall  reliability  of  the  system  outputs,  especially  those 
data  produced  from  ADS.  These  reliability  tests  cannot  be  accomplished 
satisfactorily  until  ADS  is  modified  to  include  the  damage  functions  being 
developed  by  RTI  under  Contract  No.  DCPA01-78-C-0298.  A development  plan  is 
included  to  suggest  the  implementation  of  the  present  model  for  each  of  the 
four  primary  roles  to  which  TELOS  may  be  applied. 
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A.  Background 

1.  General 

Considerable  effort  is  required  to  develop  and  maintain  a national 
civil  defense  posture  consistent  with  current  and  proposed  preparedness 
efforts.  Dynamic  modeling  of  target  and  host  areas  offers  an  effective 
technique  to  test  and  evaluate  development  alternatives  and  to  support 
planning  and  surveillance  programs.  RTI  has  participated  in  the  development 
of  TELOS  (a  system  of  computers  to  Jest  and  Evaluate  Jocal  Operating 
Systems)  and  LEMOS  (a  countermeasures  model  of  the  Local  JMergency  Operating 
System).  LEMOS  [Refs.  1-9],  a component  of  TELOS,  is  intended  to  simulate 
dynamically  the  local  civil  defense  operations.  LEMOS  is  also  capable  of 
modeling  a distributed  and  adaptive  system  that  is  critical  to  the 
survivability  of  the  country  [Ref.  10].  In  particular.  Reference  10  states, 
"In  summary,  the  development  of  distributed  survival  systems,  with  strong 
adaptive  properties,  can  both  provide  reliable  and  predictable  survivability 
and  recovery  potential  in  the  event  of  actual  nuclear  attack,  and  also 
provide  a sound  quantitative  basis  for  a useful  and  efficient  national 
emergency  preparedness  system." 

TEL0S/LEM0S  has  the  potential  to  model  multicounty  target  and  host 
area  operations  as  well  as  to  test  and  evaluate  the  consequences  of  those 
operations.  A multiyear  research  and  planning  effort  could  convert  this 
prototype  model  into  a basic  program  that  could  have  a significant  impact  on 
the  development  of  a national  civil  defense  posture. 

2.  Postures 

Program  D [Ref.  11]  envisions  crisis  evacuation  as  a "surge"  of 

actions  to  upgrade  host  area  protection  for  evacuees  and  in-place  protection 
for  non-evacuees.  Program  D 1 , while  having  essentially  the  same  goals  as 
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Program  D,  reduces  the  level  of  funding  and  defers  the  achievement  of  goals 
until  after  1983.  The  TELOS/LEMOS  concepts  support  the  dual  evacuation/ 
in-place  concepts  of  both  programs.  The  model  envisions  all  counties  as 
being  assigned  to  multi-county  groups,  either  target  or  host  types.  While 
the  model  evaluates  a single  group  of  counties,  provision  is  made  for 
resources  to  be  imported  and  exported  to  or  through  neighboring  groups. 

Thus,  while  specifically  addressing  local  civil  defense  problems,  the 
dynamic  system  is  capable  of  modeling  virtually  any  posture. 

3.  Issues 

Development,  deployment,  and  surveillance  of  an  effective  civil 
defense  system  involves  the  timely  resolution  of  a number  of  critical  issues 
[Ref.  12].  TELOS/LEMOS  has  the  potential  for  estimating: 

• Dynamic  City  Evacuation 

• Economic  Modeling  and  Impact 

• Industrial  Protection  and  Recovery 

• State/Local  Organizational  Structure 

• Communications,  Direction,  and  Control 

• Training  Requirements  and  Techniques 

• Public  Information 

• Transportation 

• Crisis  Relocation  Planning  and  Other  Preparedness  Design  Issues 

• Physical  Protection  Techniques 

• Slanting  Techniques 

• Blast/Fire  and  Other  Effects 

• Radef  and  Remote  Sensing 
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• Health  and  Medical  Issues  and  Problems 

• Dynamic  Model  of  Victim  Needs 

• CBR  Defense  Capabilities 

4.  Roles  of  Dynamic  Modeling 

The  issues  identified  above  with  an  asterisk  may  be  addressed  at 
least  in  part  by  a dynamic  simulation  of  local  (multicounty)  operations 
which  is  under  the  direction  of  a scenario  controller  and  evaluated  by  an 
output  analyzer.  The  following  four  roles  have  been  identified  [Ref.  6] 
wherein  a dynamic  simulation  can  offer  constructive  support  to  activities  of 
DCPA: 

• Coordinate  component  research  contributions  to  local  operating 
systems 

• Prepare  damage  functions  for  national  assessment  of  civil 
preparedness 

• Evaluate  alternative  local  operating  plans  and  procedures 

• Support  local  civil  defense  training  through  operation 
simulations 

The  four  roles  identified  above  and  described  below  are  not  intended  as 
an  exhaustive  treatment  of  the  roles  for  dynamic  simulation  in  testing  and 
evaluating  local  operating  systems.  They  were  included  to  suggest  the 
potential  value  of  the  basic  computer  based  system. 

Previous  research  efforts  by  the  Research  Triangle  Institute  ( RT I ) for 
the  Office  of  Civil  Defense  [Refs.  1-9]  have  been  directed  toward  describing 
the  total  local  civil  defense  system,  synthesizing  a total  analytical 
framework,  and  synthesizing  the  basic  subsystem  elements  of  a local 
countermeasures  model. 
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a.  Component  Research  Support 
The  dynamic  simulation  may  be  used  as  a "test  bed"  for  the 

products  of  component  research  provided  the  component  study  has  been 
designed  to  yield  products  which  will  interface  with  it.  For  example,  if 
component  studies  yielded  specific  time  relationships  between  thermal 
ignition  and  room  flash  over,  the  fire  spread  submodel  planned  for  ADS  could 
assess  the  impact  of  new  time  relationships  on  firefighting  operations. 
Similarly,  if  component  studies  yielded  injury  treatment  times  and 
probabilities  of  recovery  different  from  previous  studies,  the  resulting 
effects  on  medical  operations  could  be  evaluated. 

b.  National  Assessment  of  Local  Readiness  Levels 
If  a sufficient  sample  of  local  operations  could  be 

dynamically  simulated  under  various  scenarios,  the  cumulative  results  of 
these  simulations  may  be  used  to  generate  damage  functions  amenable  to 
national  assessment  in  the  manner  suggested  by  the  Analytical  Nuclear 
Casualty  Estimation  Technique  (ANCET)  developed  for  DCPA  by  RTI  [Ref.  13]. 

As  component  research,  better  training,  or  better  planning  alter  the 
national  posture,  annual  assessments  could  be  made  to  identify  the  relative 
impact  of  each  improvement  on  assessment  outcomes.  Moreover,  these  damage 
functions  may  be  related  to  different  attack  scenarios  and  levels  of 
readiness  attributed  to  local  operating  systems. 

c.  Local  Planning  Support 

Planning  activities  result  in  a number  uf  plans  which  will 
govern  the  state-of-readiness  of  localities  either  as  target  or  host  areas. 
Manuals  [Refs.  14-15]  have  been  prepared  to  guide  local  planning 
alternatives.  Written  plans  are  amenable  to  evaluation  by  a dynamic 
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simulation.  Results  of  simulation  activities  may  be  used  to  aid  in  choosing 
between  alternative  plans  or  providing  guidance  in  creating  new  plans. 
Outputs  could  suggest  preferred  routes  to  be  used  in  relocating  the 
population,  locations  for  constructing  expedient  shelter,  better  operating 
policies  and  priorities,  and  better  deployment  of  available  civil  defense 
resources. 


i 


I 

; 


d.  Civil  Defense  Training 

A dynamic  simulation  may  be  used  in  at  least  two  ways  to 
support  the  training  of  key  civil  defense  personnel.  First,  scenarios  may 
be  constructed  in  which  key  local  civil  defense  personnel  are  permitted  to 
react  interactively  to  change  certain  inputs  to  the  simulation  or  interrupt 
and  alter  simulation  controls  at  any  time  and,  thereby,  learn  what  options 
are  available  to  him  and  how  to  manage  them  to  achieve  better  outcomes. 
Second,  simulation  runs  may  be  designed  to  support  a group  acting  together 
in  a simulated  Emergency  Operating  Center  (EOC)  in  situations  approximating 
"real  time".  While  these  two  roles  are  believed  to  be  attainable,  the 
present  model  has  not  been  designed  specifically  to  support  them.  Such 
adapatations  are  not  recommended  until  the  basic  system  has  been  proven  in 
the  other  three  roles. 

5.  Level  of  Detail 

Simulation  of  local  operations  is  practicable  by  the  use  of 
computer-based  models,  provided  the  user  avoids  too  much  detail  which 
renders  the  simulation  time-consuming  and,  therefore,  expensive.  The 
authors  believe  that,  while  the  current  TELOS  design  is  seemingly  complex, 
it  has,  in  fact,  avoided  this  pitfall  and  achieved  a suitable  balance 
between  too  little  and  too  much  detail.  The  transportation  submodel 
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described  in  Section  III  typifies  this  belief.  The  network  could  have  been 
more  or  less  detailed.  The  level  of  detail  adopted  is  thought  to  give 
enough  realism  or  bel ievabil ity  and,  yet,  not  require  endless  data 
processing. 

With  this  background,  the  objectives  of  RTI’s  current  efforts  to 
construct  a basic  dynamic  simulation  that  models  local  civil  defense 
operations  under  nuclear  attack  can  now  be  stated  in  the  proper  context. 

B.  Objective 

1.  General 

The  long  term  goal  is  to  develop  a computer  based  dynamic 
simulation  capable  of  supporting  the  Test  and  Evaluation  of  Local  Operating 
Systems  both  generically,  wherein  component  research,  training  and  national 
assessment  roles  are  pursued  and,  specifically,  wherein  planning  and 
training  roles  give  direction  to  local  systems. 

2.  Short  Term 

The  purpose  of  the  current  effort  is  to  integrate  GENUA,  LOCATE, 
ADS,  and  LEMOS  under  an  executive  control;  to  convert  TELOS  to  operate  on 
the  UNIVAC  1100/10  at  DCPACC;  and  to  demonstrate  the  ability  of  TELOS  to 
simulate  a local  Civil  Defense  operating  system's  response  to  nuclear 
weapons  effects  and  to  determine  the  effectiveness  of  this  response. 

3.  Current  Contract 

The  Statement  of  Work  in  Contract  No.  DCPA01-77-C-0238  is  as 

follows: 

Based  upon  prior  research  and  development  uhich  produced  (a)  the 
TELOS  Attack  Environment  model,  (b)  the  TELOS  Area  Damage  Summary 
model,  and  ( a)  the  TELOS  Local  Emergency  Operating  System  model, 
develop  the  currently  designed  elements  into  an  integrated 
operational  system  on  the  DCPA  UNIVAC  1100/10  computer. 
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Teat,  exercise,  and  modify  the  resulting  TELOS  computer  model  as 
necessary  to  bring  it  to  demonstrable  effectiveness . The  testing 
is  to  be  performed  utilising  a case  study  approach.  The  case 
study  design  will  be  developed  in  consultation  with  DCPA. 

C.  Technical  Approach 

The  overall  system  design  approach  evolved  from  the  Five-City  Study.  A 
three  step  process  was  employed.  In  step  one,  local  operating  systems  were 
studied  and  data  collected.  In  step  two,  these  data  were  analyzed  to 
identify,  classify  and  describe  all  elements  of  the  system.  These  analyses 
produced  descriptions  of  time  phases,  operating  areas,  problem  definitions, 
and  functions  and  controls  to  solve  problems.  In  step  three,  a system  was 
synthesized  to  permit  the  test  and  evaluation  of  alternative  countermeasure 
systems.  This  early  effort,  now  viewed  as  Phase  I,  produced  the  overall 
TELOS  system  described  in  Figure  1 [Ref.  9].  At  that  time,  RTI  was 
involved  in  only  two  of  the  subsystems;  namely.  Attack  and  Countermeasures. 

From  this  simple  overall  design  concept,  the  technical  approach  to  the 
computer  based  system  development  envisioned  four  subsequent  phases: 
subsystem  design  and  coding;  system  integration  tests;  demonstration  tests; 
and  case  study  effort  including  case  planning,  simulation  execution  and  data 
evaluation.  This  early  approach  anticipated  only  the  fulfillment  of  the 
role  of  system  evaluation  for  component  research  during  the  transattack 
period.  If  other  roles  were  to  be  fulfilled,  additional  phases  would  be 
needed. 

The  current  overall  design  concept  envisions  interactive  procedures  for 
the  control  and  evaluation  subsystems  and  batch  procedures  for  the  remaining 
subsystems. 


Figure  1.  Overall  TELOS  System 


0.  Organization  of  Report 

The  manner  in  which  this  concept  has  been  implemented  is  described  in 
Section  II.  The  system  development  status  is  described  in  Section  III  in 
the  context  of  the  development  plan  in  the  next  section.  A proposed  overall 
program  plan  envisioning  the  fulfillment  of  all  roles  is  presented  in 
Section  IV.  The  overall  situation  is  discussed  in  Section  V,  followed  by 
conclusions  and  recommendations  in  the  last  section. 
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A.  Overview  of  System 

Initially,  the  system  user  plans  the  scenario  and  controls  inputs 
required  to  meet  his  evaluation  requirements.  Since  neither  the  control 
module  nor  the  evaluation  modules  have  been  developed  as  yet,  these  modules 
in  the  system  are  not  well  defined.  However,  RTI's  current  concepts 
regarding  them  are  contained  in  subsections  C and  G,  respectively.  The 
remaining  modules  are  well  defined. 

TELOS  functions  under  a set  of  controls  which  govern  an  attack  module 
that  generates  overpressure,  thermal,  and  nuclear  radiation  levels  at 
various  points  over  the  entire  local  area.  The  local  area  is  described  by  a 
data  base  that  can  be  varied  by  control  inputs.  The  Area  Damage  Summary 
(ADS)  module  relates  the  resources  to  the  environment  levels  and  describes 
the  resulting  damage.  The  local  countermeasures  module  (LEMOS)  responds  to 
problems  derived  from  evaluation  and  "surge"  period  plans  or  an  examination 
of  resource  damage  after  each  attack  event.  Through  various  counter- 
measures, LEMOS  either  protects  resources  from  subsequent  damage  or  expends 
resources  to  relieve  the  distress  resulting  from  the  weapon  effects.  In 
either  case,  the  location  and  state  of  local  resources  are  altered. 

An  iterative  or  c(ynamic  process  between  the  countermeasures  and  damage 
assessment  modules  conducts  operations  through  a number  of  time  periods 
dictated  by  system  control.  An  evaluation  module  analyzes  the  outputs  from 
both  ADS  and  LEMOS  with  respect  to  the  particular  role  of  TELOS.  On  the 
basis  of  this  evaluation,  controls  for  further  data  generation  are 
determined  and  a new  cycle  begins.  If  evaluation  goals  with  respect  to  the 
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roles  being  performed  by  TELOS  are  achieved,  appropriate  reports  are 
generated  that  reflect  the  outcome  with  respect  to  these  goals. 

Figure  2 is  a hierarchial  diagram  or  Volume  Table  of  Contents  (VTOC) 
identifying  all  of  the  elements  of  the  "dynamic"  TELOS  system.  Another 
version  of  the  system  called  the  "static"  version  does  not  contain  the 
scenario,  countermeasures  or  evaluation  modules. 

B.  Resident  Main  Program  (DCPA  MAIN) 

The  overall  control  of  the  TELOS  sytein  of  programs  is  maintained  by  a 
core  program  which  remains  in  residence  throughout  the  user  session.  The 
system  operates  in  overlay  as  described  in  an  earlier  report  [Ref.  9]  and 
calls  into  the  system  the  modules  required  to  implement  specific  functions 
involved  in  the  evaluation  of  local  operations.  The  system  is  controlled  by 
initial  inputs  or  inputs  at  designated  break  points  defined  at  the  time  of 
initial  inputs.  Initial  and  breakpoint  inputs  are  secured  through  the 
scenario  module. 

C.  Scenario  Module  (CONTROL) 

Inputs  are  planned  to  be  controlled  by  this  module  by  interactive 
methods.  The  purpose  of  these  inputs  is  to  define  the  exogenous  events, 
weather,  higher  executive  decisions  [Ref.  15],  and  other  factors  influencing 
the  evaluation;  local  plans,  policies,  priorities,  limitations  and 
procedures;  prevailing  local  situations;  reference  tables  concerning  team 
performance  and  organization;  and  output  data  requirements  for  the 
evaluation  module  together  with  controls  over  the  final  evaluation  results. 

A list  of  controls  is  shown  in  Table  I.  This  list,  in  part,  is  used  by 
LEMOS  and,  when  expanded,  may  serve  for  TELOS.  Defaults  for  all  inputs  will 


1.  Hours  from  beginning  of  scenario. 

2.  Duration  of  current  period,  in  hours. 

3.  Sequence  number  of  current  period. 

4.  Flag  to  indicate  whether  or  not  there  was  a previous  period. 

5.  Code  for  minimum  PF  level  for  shelter  spaces  to  be  used. 

6.  Code  for  maximum  height  for  shelter  spaces  to  be  used. 

7.  Low  radiation  level  (RADS)  for  defining  the  basic  operating  situation 
(BOS). 

8.  High  radiation  level  (RADS)  for  defining  BOS. 

9.  Low  fire  level  (fraction  of  area  aflame)  for  defining  BOS. 

10.  High  fire  level  (fraction  of  area  aflame)  for  defining  BOS. 

11.  Codes  for  defining  five  depths  of  debris. 

12.  Zone  number  of  area  being  studied. 

13.  Level  of  PF  provided  by  being  in  automobile. 

14.  Length  of  work  shift,  in  hours. 

15.  Fraction  of  casualties  who  are  ambulatory,  for  fifteen  (15)  injury 
categories. 

16.  Maximum  number  of  teams  to  be  assigned  to  one  problem. 

17.  Identification  of  sanctuary  area  for  this  zone. 

18.  Priority  ranking  of  operations. 

19.  Code  to  indicate  whether  or  not  CD  can  appropriate  resources  from 
residences. 

20.  Code  to  indicate  whether  or  not  population  is  warned. 

21.  Weights  used  to  compute  measure  of  effectiveness. 


minimize  the  amount  of  interactive  time  required  to  initiate  the  more 
frequently  used  controls.  A program  prototype  (PGMO)  for  this  module  was 
initiated  some  time  ago  to  permit  the  generation  or  alteration  of  the  master 
file  and/or  reference  file.  With  some  modifications  this  program  may  serve 
as  a scenario  module.  It  may  also  be  combined  with  the  program  called 
GENUA,  that  was  developed  by  DCPACC  to  describe  the  target  and/or  operating 
areas. 

D.  Target  Module  (GENUA) 

The  unit  areas  within  the  target  (GENUA)  module  are  composed  of  from 
one  to  eight  census  tracts  as  defined  in  the  1970  census.  The  criteria 
involved  in  determining  a unit  area  include  uniformity  of  size,  conformity 
to  political  subdivisions,  and  availability  of  information  about  these 
areas. 

The  calculations  involved  in  finding  the  latitude  and  longitude  of  each 
unit  area  have  been  developed.  The  area  of  each  census  tract  in  a 
particular  unit  area  is  divided  by  the  total  area  of  the  unit  giving  a 
fraction  for  each  census  tract.  Next,  the  latitude  and  longitude  for  each 
census  tract  are  multiplied  by  its  respective  fraction.  These  products  are 
added  for  all  census  tracts  within  a unit  area  giving  the  latitude  and 
longitude  of  the  centroid  of  the  unit  area. 

GENUA  is  an  interactive  program  that  allows  the  operator  to  develop  a 
target  area  based  on  typical  unit  areas  having  the  following  building 
characteristics: 

RS  = Single-Family  Residential 
RM  = Mixed  Residential 
RC  = Res i dent ial-Commeri cal 
CR  = Commercial-  Residential 
CS  = Commercial -Single 
CM  = Commercial -Mixed 
IN  = Industrial-Commercial 
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Data  concerning  these  typical  classes  are  called  up  from  a reference 
file  to  aid  in  building  the  operating  area  model.  A <'-'ven  unit  area  may 
have  more  than  one  of  these  land  use  classes.  Each  unit  area  has  a centroid 
defined  by  latitude  and  longitude.  This  module  has  not  been  modified  to 
generate  a master  file  containing  the  civil  defense  resources  needed  by  the 
countermeasures  module. 


At  present  GENUA  does  not  have  any  subroutines.  It  generates  a master 
file  for  use  by  ADS  along  with  an  attack  environment  file  from  LOCATE  as 
described  in  the  next  subsection. 

E.  Attack  Module  (LOCATE) 

A set  of  weapons  defined  in  the  scenario  is  used  by  LOCATE  to  determine 
the  attack  environments  in  each  of  the  unit  areas  defined  in  the  target 
module.  The  master  file  from  GENUA  is  processed  to  determine  the  location 
of  each  area.  LOCATE  was  developed  from  a model  called  ANCET  [Ref.  13]  and 
still  includes  some  of  its  subroutines.  Figure  3 shows  the  elements  of 
LOCATE.  The  UNSCLZ  subroutine  uses  the  WSEG-10-NAS  model  to  calculate  the 
unshielded  radiological  dose  for  the  population  center.  The  other 
subroutines  determine  either  the  geometric  relationships  between  weapons  and 
unit  areas  or  they  calculate  initial  radiation,  thermal  energy  or  fallout 
values  for  these  areas.  The  output  is  a file  of  weapon  effects  by  period 
and  by  unit  area.  Parameters  which  are  recognized  in  LOCATE  for  each  weapon 
are: 


• Latitude 

• Longitude 
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Fission/Fusion  Ratio 
Height  of  Burst 
Wind  Velocity 
Wind  Direction 
Time  of  Detonation 
Vi  si bi 1 ity 
Ai r Density 
Cross  Wind  Shear 
Attack  Start  Time 
Initial  Time  Interval 
Second  Interval  Start  Time 
Second  Time  Interval 
The  program  operator  is  able,  under  this  module's  control,  to  change 
interactively  some  of  the  attack  characteristics  listed  above.  These 
changes  will,  upon  assessment  in  the  area  damage  summary  module,  change  the 
effects  on  the  resources  in  the  target  area. 

F.  Area  Damage  Summary  Module  (ADS) 

ADS  interfaces  with  the  attack  module,  which  provides  input  for 
necessary  environmental  effects  data.  The  initial  Master  Status  File  (MSF), 
organized  by  unit  area,  contains  the  target  area  description,  the 
structures,  shelter,  and  personnel  status  records,  and  special  civil  defense 
resources  records. 

Figure  4 shows  the  organization  of  this  module  with  respect  to  its 


subroutines.  GETMST  gets  unit  area  data  from  the  master  status  file 
ADVTME  advances  time  for  fire  spread  and  injury  deaths.  GETEFF  gets 
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environmental  effects  from  the  file  produced  by  LOCATE.  The  assessment  of 
damage  is  accomplished  in  ASSESS  and  the  output  file  is  produced  by  PVTMST. 
The  PRTHDR  and  PRTHIS  subroutines  print  out  unit  area  status  and  an  output 
report  describing  facility,  shelter  and  casualty  status.  Two  auxiliary 
programs  PRTEFF  and  PRTYCH  are  also  available  to  describe  the  attack 
conditions  and  multitych  files  respecti vely. 

Thus,  while  the  primary  output  of  ADS  is  a new  MSF,  reports  can  be 
printed  or  suppressed  as  desired.  Furthermore,  the  ADVTME  subroutine  is 
available  to  increment  the  attack  scenario  over  time  to  give  a dynamic 
character  to  the  damage  assessment. 

The  ADS  updates  the  MSF  for  each  unit  area  and  time  increment.  In  all 
unit  areas,  the  prompt  effects  of  the  initial  detonation  are  assessed  for 
both  target  area  and  inventory;  persistent  effects  are  then  assessed  by 
single  time  increments  unless  additional  nuclear  detonations  occur  or  the 
evaluation  period  ends.  If  additional  nuclear  detonations  occur,  prompt 
effects  assessment  is  performed  before  continuing  the  persistent  effects 
assessment.  Damage,  casualties,  entrapments,  and  debris  levels  are 
determined  on  the  basis  of  triptychs  or  multitychs,  which  indicate  the 
degree  of  damage  and  casualties  from  blast,  fire,  and  radiation  by  structure 
type,  personnel  posture,  and  type  of  casualty  according  to  the  effects  data 
provided  by  the  attack  module.  The  output  of  ADS  is  the  updated  MSF.  These 
records  reflect  the  current  situation  including  the  availability  and  the 


condition  of  resources. 
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G.  Countermeasures  Module  (LEMQS) 

Figure  5 shows  the  major  elements  that  make  up  the  LEMOS  module.  The 
following  paragraphs  describe  briefly  each  of  the  major  elements  which 
define  the  countermeasure  activities. 

Organization  of  civil  defense  countermeasures  to  meet  undesirable 
situations  begins  with  the  problem  definition  (PROB)  submodel.  Each 
resource  in  the  MSF  is  examined  with  respect  to  its  damage  stage  and 
environment.  A set  of  problems  is  identified  which  requires  that  a 
countermeasure  be  conducted  to  solve  or  improve  the  situation.  Availability 
of  CD  resources  is  defined  by  a resource  matrix  organized  by  land  use  or 
service  function  and  resource  type  associated  with  each  function.  The 
output  of  the  problem  definition  submodel  is  a Resource  File  and  a Problem 
File  containing  four  general  classes  of  problems:  control,  readiness, 
damage  control,  and  relief  and  rehabilitation.  The  objective  of  LEMOS  is  to 
resolve  all  of  these  problems.  The  first  function  of  the  requirements 
(REQS)  submodel  is  to  update  service  records  and  identify  increased 
readiness  and  control  problems.  Then,  each  problem  is  addressed  by 
selecting  alternative  operations,  each  of  which  is  designed  to  solve  the  set 
of  problems  confronting  the  people  and/or  teams  residing  in  that  unit  area. 
Team  assignments  are  determined  that  will  implement  any  of  these 
alternatives.  The  output  of  the  requirements  submodel  is  an  Operations  File 
that  records  the  alternative  solutions  to  all  problems  defined  by  the 
Problem  File  and  an  Assignment  File  that  records  each  function  in  each 
operation.  In  addition,  a service  file  is  produced  that  defines  team 
status. 
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The  transportation  (TRANS)  submodel  contains  a series  of  programs  that 
determine  the  minimum  transportation  times  between  unit  areas.  Freeways 
and  major  arteries  are  the  basis  of  the  current  development  of  the 
transportation  network.  Residential  and  feeder  streets  are  not  included  as 
they  unnecessari ly  expand  the  network  to  unmanageable  proportions. 

The  output  from  this  submodel  is  a Travel  Reference  (TVLREF)  File  that 
quantifies  the  travel  time  between  unit  areas  after  considering  the  damage 
and  operating  environments  affecting  the  transportation  system  in  the  zone 
of  operations. 

The  assignment  (ASGN)  submodel  uses  the  operations  and  initial 
Assignment  File  from  the  requirements  submodel  and  the  Travel  Reference  File 
from  the  transportation  submodel.  The  number  of  teams  and  the  average  time 
each  team  requires  to  implement  each  operation  are  used,  subject  to 
constraint,  to  determine  assignments  for  all  teams  under  the  jurisdiction  of 
a specified  control  point.  This  allocation  procedure  [Ref.  3],  an 
adaptation  of  an  efficient  algorithm  developed  by  RTI  [Refs.  16-17], 
assigns  resources  to  alternative  programs. 

Planning  for  team  and  supply  distribution  over  the  network  of  lines  and 
links  is  accomplished  in  the  deployment  (DEPLOY)  submodel.  A minimum  Route 
(TVLREF)  File  was  generated  in  the  transportation  submodel  for  all  moves 
between  admissible  origins  and  destinations  within  a network.  This  file  was 
used  to  generate  the  Trip  File  as  the  primary  output  of  the  deployment 
submodel . 

Normally,  deployment  is  made  possible  at  the  beginning  of  the 
operations  phase  at  rates  specified  by  two  trip  records  generated  in  the 
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deployment  submodel.  These  two  records  are  sorted  into  origin  and 
destination  locations  in  a sorting  operation  between  the  deployment  and 
operations  submodels.  Operations  records  are  processed  in  the  operations 
(OPS)  submodel  by  priority  in  the  presence  of  assignment  records  organized 
by  area,  operation  number,  and  land  use.  Available  resources  are  expended 
in  exchange  for  problem  resolution.  Changes  in  resource  states  are  recorded 
in  the  Benefit,  Problem,  and  Resource  Files. 

The  Benefit  File  is  used  in  the  report  generating  (RPT)  submodel  to 
describe  benefits,  readiness,  and  team  effectiveness.  The  changed  Resource 
and  Problem  Files  are  input  to  the  final  step  in  the  countermeasures  module 
before  redefining  the  resource  status  and  recording  the  vulnerablity  in  the 
Inventory  Status  File.  The  first  is  a Performance  File  generated  in  the 
operations  submodel.  It  contains  team  performance,  population  benefits,  and 
readiness  information.  The  second  file  contains  historical  operations  data 
from  previous  periods.  The  program  has  the  capability  of  plotting  data  from 
the  two  files  to  allow  visual  scanning  for  significant  changes  over  time. 

The  final  module  in  the  LEMOS  series  of  programs  is  called  the 
inventory  protection  <INV)  submodel.  People  are  loaded  into  shelters,  and 
inventory  records  are  prepared  according  to  the  control  policy  and  posture 
constraints  prevailing  at  each  location.  This  model  uses  the  Problem  and 
Resource  Files  from  the  operations  submodel  to  update  the  status  of 
resources  in  the  MSF  from  the  damage  assessment  (ADS)  submodel. 

At  this  point  in  the  evaluation,  one  pass  has  been  completed  through 
the  countermeasures  module  by  taking  the  Master  Status  File  from  the  damage 
assessment  (ADS)  submodel  and  returning  a modified  file  to  reflect  civil 
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defense  countermeasures  during  the  specified  time  interval.  In  the  course 
of  planning  and  executing  the  specified  countermeasures,  a number  of  files 
were  created,  modified,  and  retained  for  the  next  process  period. 

Processing  continues  until  the  number  of  time  periods  required  by  the  system 
control  submodel  terminates  the  simulation.  A large  number  of  printout 
options  provided  within  the  LEMOS  and  ADS  yields  a running  description  of 
system  performance.  Output  data  may  be  processed  by  the  evaluation  module 
at  the  conclusion  of  each  pass  or  at  the  time  of  scenario  termination. 

H.  Evaluation  Module  (EVAL) 

While  this  module  has  not  been  developed,  its  basic  functions  include 
the  analysis  of  the  outputs  generated  from  ADS  and  LEMOS.  The  purpose  of 
system  evaluation  is  primarily  that  of  providing  information  concerning  the 
effects  of  changes  to  the  system  (inputs  or  models)  on  the  output  variables. 
For  the  total  CD  system  or  a subsystem  within  it,  measures  of  benefits  are 
derived  from  a comparison  of  performance  among  alternative  strategies  or 
sets  of  resources  performing  under  similar  circumstances.  In  this  context, 
system  evaluation  will  facilitate  the  resolution  of  questions  such  as: 

(1)  What  are  the  most  effective  CD  plans  and  policies  for  a given 
local  operating  system?  How  sensitive  are  the  optimal  plans  to 
changes  in  the  inputs? 

(2)  How  do  uncertainties  in  the  inputs  and  TELOS  models  affect  the 
predicted  outcome  consequences?  What  are  the  input  parameters  for 
a given  strategy  that  have  the  greatest  influence  on  the 
effectiveness  of  the  countermeasures? 
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(3)  What  is  the  most  effective  plan,  assuming  the  "worst"  attack 
scenario  for  this  region?  How  should  local  operating  decisions 
take  into  account  the  potential  for  multiple  weapon  detonations 
during  the  transattack  period? 

(4)  What  are  the  survival  probabilities  considering  uncertainties  in 
the  input  parameters  defining  the  attack  scenario  and  the 
effectiveness  of  CD  countermeasures? 

(5)  What  are  appropriate  measures  of  CD  effectiveness?  How  should 
the  mul ti attribute  nature  of  the  figure  of  merit  be  treated  in  the 
system  evaluation?  How  does  the  optimality  of  the  various 
possible  countermeasure  strategies  vary  according  to  the  different 
possible  methods  of  combining  individual  attributes  (e.g., 
injury-free  surviving  population,  subsistence  capacity,  surviving 
industrial  capacity,  etc.)? 

There  are  three  distinct  elements  that  must  be  developed  in  the 
evaluation  methodology  for  the  consideration  of  questions  such  as  these  in 
the  assessment  of  alternative  CD  strategies.  The  first  involves  the 
determination  of  appropriate  measures  of  CD  effectiveness,  as  suggested  in 
question  5 above.  This  part  of  the  evaluation  is  termed  value  or  util ity 
analysis  and  is  concerned  with  the  specification  of  valuation  preferences  of 
CD  objectives  as  they  pertain  to  the  outcome  consequences  predicted  by 
TELOS.  By  developing  proper  measures  that  reflect  CD  objectives  and 
recognizing  the  multiattribute  aspect  of  these  goals  [Ref.  18],  alternative 
plans  and  strategies  can  be  systematically  evaluated  to  ensure  the 
maximization  of  these  objectives.  The  second  element  of  the  evaluation 
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module  is  sensitivity  analysis,  i.e.,  the  identification  of  the 
significant  variables  and  the  importance  of  uncertainties  in  these 
variables.  Through  sensitivity  analysis,  answers  can  be  obtained  to  a 
variety  of  important  questions,  such  as  1,  2,  and  4 above.  Using  methods 
that  rely  on  experimental  design  techniques,  group  screening,  response 
surface  methodology,  and  Monte  Carlo  techniques,  the  important  statistical 
as  well  as  operational  characteristics  of  a particular  CD  plan  can  be 
assessed.  The  final  component  of  the  system  evaluation  involves  the 
appl ication  of  decision  analysis  methods  to  alternative  CD  strategies. 

Using  the  results  of  the  value  analysis  and  sensitivity  analysis, 
alternative  plans  can  be  systematically  evaluated  and  the  optimal  decision 
sequence  identified.  Strategies  that  maximize  the  expected  value  benefits 
of  CD  operation  under  conditions  of  risk  can  also  be  compared  to  those  that 
minimize  CD  losses  under  the  worst  case  scenarios.  Contingency  plans  can  be 
developed  that  reflect  the  valuation  preferences  of  national  as  well  as 
local  CD  planners.  In  the  following,  a brief  discussion  is  made  of  each  of 
these  three  major  elements  that  are  necessary  for  the  system  evaluation 
module  of  TELOS. 

1.  Measure  of  CD  Effectiveness 

The  information  generated  and  processed  in  TELOS  can  be  considered 
to  define  an  entire  range  of  attributes,  each  of  which  may  be  a measure  of 
the  benefits  or  effectiveness  of  CD  operations.  System  performance 
objectives  may  include  population  survival,  postattack  survival 
capabilities,  industrial  protection  and  recovery  capabilities,  etc.  The 
attributes,  or  criteria,  that  determine  the  degree  to  which  such  objectives 
are  realized  could  include  communications,  transportation,  shelter 
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protection,  housing,  fire,  medical  considerations,  etc.  In  evaluating 
multiple  objectives,  the  problem  of  value  tradeoffs  is  implied  in  the  choice 
of  one  plan  over  another  if  no  one  CD  strategy  dominates  other  alternatives. 
The  value  analysis  involves  the  generation  of  a proper  objective  heirarchy, 
selecting  attributes  for  these  objectives,  and  developing  tradeoff 
preferences  and  functions  for  use  in  the  decision  analysis.  Sequential 
elimination  techniques  [Ref.  19],  using  the  methods  of  dominance  and 
constraints  can,  in  some  cases,  eliminate  alternative  strategies,  but 
weighting  techniques  and  mul tiattribute  utility  theory  will  be  required  for 
a general  assessment  of  CD  effectiveness. 

Several  measures  of  CD  effectiveness  have  been  previously  suggested 
[Ref.  6]  and  include  the  following: 

® Relative-Well-Being  (RWB) 

• Readiness  (RDY) 

» Team  Effectiveness  (E) 

• Cost  (C) 

These  measures  were  suggested  to  provide  information  that  described, 

respectively,  the  relative  state  of  the  population  at  a point  in  the 

emergency  period,  the  potential  for  gain  due  to  civil  defense  activity  and 
the  value  of  preattack  preparations,  the  effectiveness  of  team  operations, 
and  the  expenditure  of  team-hour  resources.  Weighting  schemes  were  employed 
to  combine  the  pertinent  attributes.  For  example,  the  RWB  measure  employed 
such  attributes  as  surviving  population  (S-t),  labor  potential  of  survivors 
(Lt),  production  capacity  (Vt),  and  housing  capacity  (Hc).  The  attributes 
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In  the  formal  development  of  the  system  evaluation  module,  other 
measures  of  effectiveness,  in  conjunction  with  the  possible  use  of 
inul tiattribute  utility  theory  to  assess  tradeoff  preferences  in  the  CD 
objective  hierarchy,  will  need  to  be  considered.  This  will  ensure  that  the 
measures  of  effectiveness  are  rationally  developed  and  also  consistent  with 
CD  goals. 

2.  Sensitivity  Analysis 

With  properly  developed  measures  of  CD  effectiveness,  a systematic 
analysis  of  the  sensitivity  of  TELOS  is  the  second  integral  part  of  the 
evaluation  module.  For  the  system  of  computer  models  that  form  TELOS,  the 
assessment  of  system  sensitivity  can  incorporate  several  of  the  statistical 
techniques  that  have  been  applied  to  other  complex  systems  (and  computer 
codes),  such  as  applications  in  nuclear  reactor  safety  analysis  [e.g..  Refs. 
20-21].  The  following  steps  suggest  a possible  methodology  that  could  be 
employed  for  the  sensitivity  analysis  of  TELOS: 

1.  Use  technical  knowledge  and  group  screening  methods  to  reduce  the 
number  of  important  variables  to  10  or  so  for  a given  attack 
scenario  and  target  description. 

2.  Run  a one-at-a-time  design  using  the  reduced  set  of  input  variable 
in  a 3 level  input  pattern  (i.e.,  u-4a,  u,  u + 4a).  Plot  the 
results  for  indication  of  relative  importance  and  further 

el imination. 

3.  Augment  the  one-at-a-time  design  to  create  more  levels  for  any 
variables  that  may  require  transformation  to  make  their  behavior 
more  linear. 
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4.  Construct  an  appropriate  fractional  factorial  design  in  the 
remaining  variables  so  as  to  comprise  a reasonable  response 
surface  design  and  fit  the  surface. 

5.  Use  Monte  Carlo  methods  on  the  fitted  response  surface  to  compute 
the  probabilities  of  the  various  predicted  outcome  consequences. 

This  type  of  approach  would  provide  for  a systematic  identification  of 
the  most  critical  parameters  in  the  evaluation  of  a particular  CD  strategy. 
The  methodology  would  also  facilitate  the  modification  and  refinement  of  any 
TELOS  models  by  identifying  the  most  important  parameters.  It  would  be 
possible  to  rank  the  variables  in  terms  of  their  contribution  to  the 
particular  measure  of  CD  effectiveness  considered.  Finally,  the  developed 
response  surface  function  will  permit  the  estimation  of  the  likelihood  or 
probabilities  that  the  measures  of  CD  effectiveness  are  achieved  for  a given 
local  CD  plan. 

3.  Decision  Analysis 

The  final  component  of  the  evaluation  module  is  the  analysis  of 
alternative  CD  plans  and  policies.  Decision  analysis  methodology  [e.g., 
Refs.  22-23]  provides  a rational  means  to  determine  optimal  strategies  in 
the  presence  of  uncertainty.  In  the  context  of  CD  operations,  uncertainty 
can  be  considered  to  exist  in  the  specification  of  the  attack  scenario,  the 
effects  of  weapons,  the  effectiveness  of  CD  countermeasures,  etc.  This 
uncertainty  can  be  treated  in  several  ways  according  to  the  traditional 
classes  of  decision  analyses  problems.  Decision  analysis  under  conditions 
of  risk,  uncertainty,  or  conflict  can  be  applied  according  to  the  amount  of 
information  available  about  the  various  states  that  may  occur.  A major 
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advantage  of  using  decision  analysis  formalism  is  that  alternative 
strategies  can  be  evaluated  with  respect  to  their  degree  of  information 
sensitivity.  The  value  of  perfect  information  for  each  of  the  input 
variables  can  be  assessed.  The  expected  value  of  perfect  information  (EVPI) 
thus  calculated  represents  the  maximum  value,  in  terms  of  the  CD  measure  of 
effectiveness,  that  additional  information  is  worth  to  the  local  CD  system. 
Thus,  a quantitative  measure  of  information  and  modeling  sensitivity  is  a 
by-product  of  the  use  of  decision  analysis  in  the  evaluation  module. 

In  summary,  the  decision  analysis  component  of  the  system  evaluation 
provides  a logical  tool  to  access  CD  emergency  operation  alternatives  and 
the  value  of  perfect  information  to  local  CD  systems.  When  coupled  with  the 
sensitivity  and  value  analysis  components  of  the  evaluation  module,  a 
comprehensive  methodology  exists  for  evaluating  local  CD  systems,  plans,  and 
policies  using  the  TELOS  models. 
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A.  General 

The  overall  TELOS  system  is  still  incomplete  although  many  of  its 
elements  are  essentially  defined.  The  primary  activity  during  the  current 
contract  has  been  concerned  with  testing  and  conversion  of  the  LEMOS 
elements.  The  status  with  respect  to  testing  and  conversion  is  described  in 
the  next  two  subsections.  In  Subsection  D the  deficiencies  of  the  system 
are  identified  and  described  as  a basis  for  the  plan  proposed  in  Section  IV. 

B.  Testing  and  Demonstration 

Tests  to  date  have  been  concerned  with  single  and  multi-area  runs 
through  successive  submodels  of  LEMOS.  Figure  6 shows  the  complex  file 
relationships  between  submodels.  Files  identified  in  Table  II  for  selected 
successive  steps  in  the  countermeasures  module  are  described  in  Appendix  A. 
Note  that  only  twelve  (12)  files  are  included  for  exhibition  purposes.  If 
all  files  had  been  included,  the  output  would  have  been  too  voluminous. 
Therefore,  Appendix  B contains  just  twelve  examples  of  the  test  files  that 
were  operated  on  or  modified  by  the  test  runs.  These  files  are  based  on  the 
selection  of  two  unit  areas  from  the  Detroit  city  data  base  prepared  earlier 
[Ref.  2].  The  two-unit-area  master  file  was  developed  to  reflect  a series 
of  problems  which  were  designed  to  test  the  system's  procedures  but  not  to 
serve  as  a demonstration  of  its  capabilities.  The  deficiencies  described  in 
Subsection  D prevented  not  only  a satisfactory  demonstration  of  the  ADS  and 
LEMOS  interfaces,  but  also  an  iteration  of  both  through  successive  time 
periods.  Thus,  the  tests  conducted  during  the  contract  period  were 
undertaken  to  demonstrate  the  unity  and  effectiveness  of  the  file  management 
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DDNAME 

Description 

Cobol 

FILE1 

PR0B1 

FILE2 

MASTER  1 

FILE3 

PR0B2 

FILE4 

RES0URCE1 

FILE5 

MASTER  2 

FILE6 

REFERENCE 

FILE12 

ORGN 

FILE13 
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FILE15 
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FILE16 
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FILE19 

SERVICE2 

FILE20 
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FILE21 
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FILE22 
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FILE23 
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FT94F001 
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^Appendix  B contains  the  12  identified  examples  of  the  test  files. 
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and  main  model  overlay  procedures  and  not  to  serve  as  a formal  demonstration 
of  one  or  more  of  the  roles  for  the  system  set  forth  in  Section  I,  page  1-3. 
These  tests  are  believed  to  show  that  the  currently  designed  elements  have 
now  been  merged  into  an  integrated  system  on  the  DCPACC's  UNIVAC  1100/10 
computer.  However,  even  though  they  have  been  integrated,  the  system  cannot 
be  said  to  be  operational.  Operational  status  cannot  be  achieved  until 
some,  but  not  necessarily  all,  of  the  deficiencies  described  in  Subsection  D 
are  resolved. 

C.  Conversion 

All  existing  modules  and  submodels  described  in  the  previous  section 
have  been  converted  to  operate  on  the  UNIVAC  1100/10  computer  at  Olney, 
Maryland.  That  is,  the  same  multi-area  test  runs  have  been  successfully 
made  on  that  machine.  The  files  included  in  Appendix  B were  developed  on 
the  IBM  370/165  at  the  Triangle  Universities  Computation  Center.  They  were 
used  to  confirm  that  the  conversion  to  the  UNIVAC  1100/10  was  complete  when 
these  same  outputs  were  produced  by  similar  runs  at  DCPACC. 

D.  Deficiencies 

A number  of  deficiencies  remain  to  be  overcome  before  the  TEL0S  system 
can  be  said  to  be  usable.  The  following  list  identifies  the  more 
significant  shortcomings  of  the  present  system. 

• Scenario  Module 

• Evaluation  Module 

• Data  Base  for  GENUA  and  LEM0S 

• Damage  Functions  for  CD  Resources 

• Damage  Assessment  in  ADS  for  CD  Resources 
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• Fire  Model  in  ADS 

• Utility  Network  Model  in  LEMOS 

• Self-Help  Countermeasures 

• Communications  Submodel  in  LEMOS 

« Queuing  Submodel  to  Define  Congestion  Problems 

• Preattack  Operating  Plans  in  LEMOS 

• Reference  Files  for  LEMOS 

Each  of  the  above  deficiencies  will  be  discussed  in  the  following 
paragraphs  and  related  to  the  overall  program  plan  in  Section  IV. 

1.  Scenario  Module 

This  important  module  is  fragmented  and  incomplete.  Its  functions 
are  now  implemented  in  part  by  interactive  methods  within  GENUA, 
LOCATE,  ADS,  and  Pgm  0 (for  LEMOS).  All  interactive  inputs  should 
be  consolidated  into  a single  module  defined  as  the  scenario 
module.  Moreover,  this  module  should  be  linked  with  the 
evaluation  module  to  insure  that  a complete  analysis  of  local 
operations  will  yield  results  which  are  consistent  with  the  role 
chosen  for  TELOS. 

2.  Evaluation  Module 

Both  ADS  and  LEMOS  are  capable  of  yielding  a large  number  of 
outputs  for  a single  time  period,  still  more  for  multiple  time 
periods  within  a single  scenario,  and  enormous  amounts  of  data  for 
alternative  scenarios.  Therefore,  an  evaluation  module  is  needed 
which  will  plan  the  scenario  set,  process  the  outputs  and  provide 
sufficient  summary  data  to  permit  the  user  to  achieve  his 
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objectives.  Since  there  are  four  potential  roles  for  TELOS  as 
described  in  Section  I,  page  1-3,  it  may  be  necessary  to 
have  up  to  four  different  versions  of  the  evaluation  module 
depending  on  the  roles  being  played.  A plan  for  the  development 
of  this  module(s)  should  be  prepared  after  careful  analysis  of  the 
capabilities  of  the  other  modules.  This  analysis  may  uncover 
additional  deficiencies  not  included  in  this  subsection. 

3.  Data  Base  for  GENUA  and  LEMOS 

A set  of  files  should  be  prepared  to  support  the  GENUA  module  in 
such  a way  as  to  minimize  the  amount  of  effort  required  to 
generate  an  initial  array  of  unit  areas  and  resource  records. 

These  files  should  not  attempt  to  describe  every  unit  area 
explicitly,  but  rather  contain  generic  land  use  class  and 
population  data  which  would  allow  the  implicit  development  of  each 
area.  Interactive  graphic  methods  should  be  used  to  create 
network  overlays  for  highway  and  utility  data.  Once  a generic 
description  has  been  prepared  from  file  data,  the  user  can 
interact  graphically  with  the  layout  and  alter  the  implicitly 
developed  array  with  explicit  changes  to  agree  with  scenario 
requirements.  Very  little  has  been  done  to  prepare  this  data  base 
in  a useful  form.  However,  many  of  the  data  elements  required  for 
this  file  are  available.  A complete  data  base  is  not  needed  until 
a complete  TELOS  system  has  been  developed  and  approved  for 
operational  use  in  one  or  more  roles.  Even  though  a complete  data 
base  is  not  required  at  this  time,  its  requirements  must  be 
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defined  in  detail  and  a plan  prepared  to  insure  its  compatibility 
with  the  system. 

4.  Damage  Functions  For  CD  Resources 

The  damage  functions  for  general  land  use  structure  types  and 
personnel  casualties  have  been  prepared  for  use  in  ADS.  Damage 
functions  for  other  resources  are  being  prepared  under  Contract 
No.  DCPA01-78-C-0298  with  RTI.  Some  typical  damage  functions 
which  are  needed  include  those  for: 

• Bridges 

• Vehicles 

• Radio  Transmitters/Recei vers/Towers 

• Telephone  and  Power  Lines 

o Telephone  Exchanges 

• Power  Plants 

• Gas  Gates 

• Water  Pumping  Stations 

5.  Damage  Assessment  in  ADS  for  CD  Resources 

ADS  needs  to  be  modified  to  accommodate  the  damage  functions 
described  above  and  to  enable  assessment  of  damage  to  CD 
resources.  These  resources,  including  teams,  are  identified  in 
the  MSF  on  records  with  Code  "5".  ADS  does  not  now  process  these 
records  and  some  additions  to  its  main  program  and  subroutines 
will  be  required  to  process  a complete  MSF.  This  may  be 
accomplished  as  a part  of  the  DCPA01-78-C-0298  contract  if  time 
and  funds  permit. 
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6.  Fire  Model  in  ADS 

The  present  fire  model  in  ADS  is  an  oversimplified  representation 
of  the  fire  spread  situation.  Fire  cannot  spread  across  a unit 
area  boundary  nor  is  there  any  relationship  between  highways  and 
other  potential  fire  breaks.  The  model  developed  by  the  Illinois 
Institute  of  Technology  Research  Institute  (IITRI)  and  modified  by 
the- Institute  for  Defense  Analysis  (IDA)  could  be  adapted  to  this 
role. 

7.  Utility  Network  Model  in  LEMOS 

A flow  model  is  needed  as  a part  of  the  countermeasures  model  to 
determine  the  state  of  essential  utilities,  i.e.,  water,  power, 
telephone,  and  sewage  treatment.  It  is  important  to  know  the 
capabilities  of  these  systems  in  order  to  implement  an  effective 
countermeasures  plan. 

8.  Self-Help  Countermeasures 

These  informal  actions  in  response  to  problems  involving  people 
who  are  almost  totally  divorced  from  the  formal  civil  defense 
system  must  be  taken  into  account  in  measuring  the  performance  of 
the  formal  civil  defense  organization.  These  actions  are  not 
presently  evaluated  in  LEMOS. 

Problems  can  be  solved  wholly  or  partially  by  individuals 
without  help  from  the  system.  A person  trapped  in  a damaged 
building  may  be  rescued  by  another  person  and  taken  to  an  adjacent 
undamaged  shelter  simply  because  he  sees  a problem  and  has  the 
capability  to  solve  it  immediately.  This  type  of  countermeasure 
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is  spontaneous  and  assumes  that  no  control  is  exercised.  Other 
self-help  actions  interface  directly  with  formal  civil  defense 
actions.  On  hearing  a warning  siren,  people  respond  in  various 
ways  (e.g. , ignore,  duck,  move,  or  enter  shelter)  if  no  other 
controls  exist.  Similarly,  the  emergency  broadcast  system  (EBS) 
may  provide  a stimulus  for  popular  action  which  is  basically 
uncontrolled.  Prediction  of  uncontrolled  responses  is  largely 
probabi 1 istic  and  often  based  on  experimental  statistics.  In 
order  to  consider  these  factors,  a set  of  self-help  functions  that 
process  the  defined  problems  and  change  the  magnitude  of  each 
according  to  the  response  predicted  by  the  function  is  needed. 

Only  immediate  responses  are  allowed.  No  long  term  coordinated 
actions  outside  of  the  civil  defense  system  are  allowed.  Even 
though  they  may  occur,  no  dual  civil  defense  system  is  likely  to 
increase  system  effectiveness. 

The  outcome  of  self-help  countermeasures  is  a revised  set  of 
problems  which  enter  the  information  system. 

9.  Communications  Submodel  in  LEMOS 

All  problems  are  assumed  to  be  identified  as  they  enter  the 
communications  submodel.  Reports  are  generated  by  origin  or  unit 
area  and  a priority  is  attached  to  each.  They  are  assigned  to 
communication  terminal  queues  at  responsible  control  team 
locations.  In  addition,  each  report  or  message  is  addressed 
according  to  the  organizational  structure.  Policy  constraints 
influence  both  the  priority  and  the  address  of  assignments  to 
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specific  classes  of  reports.  Reports  may  enter  the  organization 
at  any  level  subject  to  policy  control. 

The  communication  submodel  manages  the  information  flow  by 
locating,  classifying,  addressing,  and  assigning  priority  to  all 
problems. 

Time  delays  or  blockages  introduced  by  message  flow  through 
the  network  constrains  the  timeliness  of  system  response. 

The  physical  characteristics  of  the  communication  network  and 
operating  teams  are  defined  from  target  model  elements.  The  state 
of  each  link,  including  both  terminals,  is  determined  from  damage 
assessment  model  outputs. 

Message  loads  are  developed  by  propagating  messages  from 
terminal  queues  over  the  network  during  the  time  interval 
according  to  the  general  operating  policy.  Message  batches  are 
processed  by  precedence.  When  mode  handling  time  plus  link 
processing  time  is  less  than  the  time  interval,  propagation  of  the 
batch  is  continued.  If  channel  capacity  is  reached,  the 
message  batch  is  split  and  an  alternate  route  is  selected.  If  the 
queue  limit  is  reached,  the  next  alternate  route  is  selected  when 
the  load  has  progressed  as  far  as  possible  in  the  time  interval. 
All  messages  are  stored  in  queues;  when  a terminal  is  reached  by 
the  load,  the  load  is  removed  from  the  traffic. 

A communi cation  module  is  needed  to  assist  in  developing  and 
evaluating  communication  plans  (by  state  and  local  authorities). 
The  communication  plans  must  be  considered  as  a central  part  of 
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the  overall  zonal  plans  for  command  and  control.  This  effort  will 
build  upon  the  results  of  previous  efforts  [Ref.  24]  and  will 
relate  to  the  planning  role  for  TELOS.  The  design  and  implemented 
model  should  include  the  following  elements  or  attributes. 

• A description  of  the  preattack  and  postattack 
communications  network. 

• A description  of  the  essential  team  operations, 
personnel,  and  resources  required  to  implement  the 
communication  system. 

» The  necessary  and  sufficient  elements  of  an  effective 
"communi cations  plan"  must  be  described  as  it  may 
interface  with  the  TELOS  system. 

o The  vulnerability  and  evaluation  criteria  are  needed 
to  measure  planning  effectiveness. 

o Tie  design  of  an  overall  communications  model  must  be 

capable  of  measuring  the  performance  of  alternative  sets 
of  local  communication  system  resources  under  nuclear 
attack,  evaluating  the  relative  degradation  among  the 
alternatives  and  determining  the  impact  of  various 
levels  of  communication  system  degradation  on  overall 
system  effectiveness. 

10.  Queuing  Submodel  to  Define  Congestion  Effects 

While  routes  and  travel  times  are  defined  in  the  transportation 
submodel,  movements  are  accomplished  without  considering  traffic 
congestion  and  its  effect  on  travel  times.  A queuing  submodel 
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could  determine  these  effects  and  their  impact  on  countermeasure 


operations. 

Basically,  a trip  is  defined  as  a move  in  which  some  resource 
takes  a path  (represented  by  the  link)  through  an  environment. 

The  link  has  four  properties:  (1)  a gate  which  processes  trips 
one  at  a time,  (2)  a queue  which  orders  the  trips  through  the 
gate,  (3)  a pointer  which  guides  tne  trip  to  other  links,  and  (4) 
a generator  which  originates  new  trips  for  the  networks. 

Using  the  queuing  model  and  the  trip  file,  resources  are 
moved  over  the  network.  Starting  with  the  highest  level  network, 
movement  proceeds  until  all  are  at  the  lowest  (or  the  unit  area) 
level.  Unforeseen  delays  require  that  arrival  times  be  adjusted 
for  positions  attained  during  the  time  interval.  Statistics  are 
prepared  for  each  link.  Information  from  this  queuing  process 
will  be  used  for  planning  movements  during  the  next  time  interval. 
Thus,  decisions  are  being  influenced  constantly  by  events  in  the 
immediate  past.  (Correspondingly,  fallout  prediction  data  could 
be  made  to  influence  routing  by  formulating  predictions  in  a way 
similar  to  that  described  above).  Deployment  is  completed  to 
determine  arrival  times  for  teams  performing  assigned  functions. 

11.  Preattack  Operating  Plans  in  LEMOS 

No  provision  is  made  in  LEMOS  for  i ncorporati ng  preattack 
mobilization,  deployment,  crisis  relocation  or  community  shelter 
plans.  LEMOS  responds  to  transattack  problems  and  not  to 
anticipated  problems.  However,  the  present  code  may  be  adapted  to 
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include  a full  range  of  such  problems  provided  a triggering 
mechanism  is  employed  to  determine  the  time  to  respond  to  the 
anticipated  problems.  In  addition,  new  inputs  reflecting  these 
plans  must  be  structured  and  prepared.  This  deficiency  is  perhaps 
one  of  the  more  important  shortcomings  of  the  LEMOS  system  and 
should  be  corrected  as  early  as  practicable. 

12.  Reference  Files  for  LEMOS 

Certain  inherent  characteristics  of  civil  defense  operations  are 
defined  in  a series  of  tables;  for  example,  the  components  of 
teams,  alternative  operations,  or  consumption  rates  of  resources 
by  active  teams.  The  present  reference  files  contain  data  which 
was  collected  quickly  to  function  as  a test  of  the  operating 
system.  More  care  is  needed  in  researching  available  civil 
defense  reports  for  the  best  data  together  with  some  estimate  of 
the  maximum  or  minimum  values  that  could  be  used  to  represent  the 
data  element.  Again,  this  is  another  important  deficiency  that 
needs  early  resolution. 

All  of  the  above-described  deficiencies  should  be  recognized  and  a plan 
created  to  correct  each  according  to  its  importance  with  respect  to  the 
roles  planned  for  the  system.  Section  IV  suggests  a program  schedule  for 
eliminating  these  deficiencies  and  developing  an  operational  TELOS 
simulation.  While  these  deficiencies  appear  to  be  numerous,  they  represent 
a relatively  small  part  of  the  total  TELOS  system. 
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A.  General 

This  section  is  a logical  extension  of  the  previous  section  and 
attempts  to  summarize  the  development  status  in  terms  of  a program  plan 
which  will  lead  to  the  implementation  of  all  four  roles  described  in  Section 
I,  page  1-3. 

B.  Research  Role 

Assuming  that  TELOS  in  the  research  role  is  adopted  as  a basic  system, 
Table  III  shows  a development  plan  in  terms  of  person-years  of  effort  to 
complete  each  module  and  submodel  within  TELOS  for  each  prospective 
application.  The  other  roles  build  upon  this  basic  system. 

C.  National  Readiness  Assessment  Role 

A second  role  for  TELOS  could  be  national  assessment  of  civil  defense 
readiness.  This  extension  would  require  an  expanded  data  base,  an  interface 
with  a readiness  reporting  system,  and  an  interface  with  a national 
assessment  system  using  ANCET  or  similar  rapid  means  for  relating  resource 
degradation  directly  to  weapons  effects. 

D.  Planning  Role 

The  third  role  for  TELOS  is  as  a tool  for  local  civil  defense  planners. 
Since  each  local  CD  planner  is  responsible  for  his  plans,  TELOS  cannot 
assume  the  evaluative  role  for  him.  Therefore,  the  outcome  interface  must 
contain  several  alternative  means  for  evaluating  simulation  outcomes  as  they 
may  be  influenced  by  local  plans.  The  planner  should  have  not  only  the 
choice  from  among  these  alternatives  but  should  be  able  to  "tune"  the 
selected  method  to  meet  his  objectives  wherever  practicable.  Measures  for 
normalizing  outcome  measures  are  especially  important. 
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The  previous  section  contained  an  approach  to  systems  evaluation  which 
offers  a rational  means  for  improving  local  operations  through  computer 
simulation.  Additional  measures  or  evaluative  techniques  may  be  developed 
if  the  local  planner  considers  them  essential  to  the  proper  evaluation  of 
his  plans. 

This  role  requires  an  explicit  means  for  entering  local  plans  in 
the  simulation  model  and  developing  revised  plans  from  outcomes,  a 
generalized  data  base  from  which  local  target  models  can  be  efficiently 
generated,  and  interactive  methods  for  the  planner's  participation  in  the 
process. 

Perhaps  tne  greatest  impact  of  the  TELOS  system  can  be  achieved  by 
fielding  mobile  remote  terminal  units  that  can  bring  direct  computer  aided 
planning  to  the  local  level.  Obviously,  this  would  bring  a degree  of  public 
visibility  to  civil  defense,  but,  more  importantly,  it  would  bring  to  local 
personnel  the  most  advanced  and  objective  techniques  for  planning  the 
optimum  utilization  of  available  resources.  A number  of  such  units 
following  carefully  scheduled  itineraries  could  cover  the  United  States  in  a 
systematic  f^hion  and  develop  a reliable  data  base  for  national  planning. 
Plans  evolving  from  these  contacts  at  each  locality  could  achieve  a high 
degree  of  standardization,  and  yet  allow  for  local  unique  di-^^ences. 
Microprocessors  in  the  mobile  unit  can  minimize  the  effort  required  to 
convert  computer  outputs  to  detailed  local  operating  plans. 

E.  Training  Role 

Once  the  other  roles  have  been  implemented,  the  training  role  requires 
slightly  less  additional  effort  than  for  the  planning  role  to  adapt  the 
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system  to  the  training  role.  The  training  acquired  by  local  participants 
would  be  valuable  in  stimulating  interest  and  improving  direction  and 
control  of  local  operations.  The  mobile  units  would  have  capability  for 
both  remote  interactive  development  of  operational  scenarios  and  batch 
generation  of  tiinephased  computer  outputs. 

The  major  additions  to  the  system  would  focus  on  the  computer  graphics 
as  a means  for  improving  communications  between  the  trainee  and  system  and 
on  the  development  of  a set  of  scenarios  including  specific  target  areas 
where  outcomes  illustrate  the  main  points  to  be  learned  by  exercising  the 
system  [Ref.  25].  Under  these  conditions,  this  simulation  tool  could  become 
a major  asset  of  the  CD  training  center  at  Battle  Creek,  Michigan. 

F.  Development  Schedule 

Assuming  that  the  local  simulation  is  capable  of  fulfilling  the  roles 
defined  in  the  previous  subsection,  Table  IV  describes  a set  of  phases, 
including  development,  test  and  demonstration,  installation  and  support  for 
each  role.  The  installation  phase  assumes  that  some  modifications  of  the 
demonstrated  system  are  required  as  a result  of  the  demonstration  to  meet 
specific  user  requirements.  The  overall  plan  implies  that  each  subsequent 
role  builds  upon  the  product  of  the  previous  effort. 
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The  approach  to  the  development  of  a system  evaluation  methodology  is 
considered  to  be  of  primary  importance,  if  the  TELOS  system  is  to  become  an 
important  tool  in  improving  local  civil  defense  operations.  Now  t .at  the 
capabilities  of  a prototype  TELOS  system  are  clearly  delineated,  it  is 
appropriate  at  this  time  to  structure  an  evaluation  module  that  will  utilize 
the  TELOS  code  to  best  advantage.  While  the  code  is  being  tested,  refined, 
and  demonstrated,  the  evaluation  methodology  should  be  formalized  so  that 
appropriate  inputs  and  outputs  can  be  assured.  A project  for  this 
development  has  been  added  to  the  program  plan  in  Section  IV  as  a means  for 
integrating  the  evaluation  module  into  TELOS  procedures.  This  activity 
should  be  concurrent  with  the  documentation,  test,  and  demonstration 
activities  currently  planned  for  TELOS. 

Now  that  the  TELOS  system  has  been  converted  to  the  UNIVAC  1100/10 
environment  and  is  available  for  interactive  use  by  the  Research  Directorate 
and  its  contractor  through  remote  or  foreign  terminals,  it  is  propitious  to 
document  thoroughly,  test  present  code  and  correct  deficiencies  as  well 
as  fill  some  of  the  analytical  voids  now  apparent  in  the  system.  Standards 
for  this  documentation  [Ref.  26]  are  available  but  require  explicit 
decisions  in  order  to  meet  DCPACC  and  user  needs  as  well  as  those  of  the 
Research  Directorate  and  its  contractor,  RTI.  Assuming  mid-range  total 
level  of  complexity  based  on  the  twelve  factors  for  assessing  complexity  in 
the  DOD  standard  cited  above,  the  documentation  should  contain  the  following 
document  types:  a functional  description  (FD),  a Users  Manual  (UM),  a 
Computer  Operation  Manual  (OM),  a Program  Maintenance  Manual  (MM),  and  a 
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Test  Plan  (TP).  The  standard  contains  an  outline  of  each  of  these  documents 
and  these  outlines  are  reproduced  in  Appendix  C.  However,  the  standard 
allows  considerable  latitude  depending  upon  the  ADP  center's  needs  and 
desires.  Therefore,  it  is  important  that  DCPACC  establishes  the  final 
outlines  of  these  documents  and  that  they  are  developed  in  the  next  phase  of 
the  TELOS  development  program. 

The  program  plan  described  in  Section  IV  offers  a comprehensive 
approach  to  achieving  the  roles  described  for  TELOS.  While  this  plan  is 
believed  to  be  technically  feasible,  RTI  has  no  way  of  determining  whether 
it  can  be  implemented  within  funding  constraints  nor  whether  it  can  be 
integrated  with  user  program  plans.  It  is  important  that  the  entire  TELOS 
concept,  including  evaluation  and  user  roles,  be  validated  as  a part  of  DCPA 
program  planning. 

Among  the  LEMOS  deficiencies  described  in  Section  III,  the 
communication  submodel  is  considered  to  be  the  most  significant  void  to  be 
filled  next.  The  impact  of  the  submodel  in  command  and  control  is  very 
important  and  should  not  be  underestimated.  This  development  should  be 
based  on  work  discontinued  at  RTI  some  years  ago  [Ref.  24]. 

Finally,  the  priorities  attached  to  each  line  item  in  the  program  plan 
need  to  be  determined.  RTI  has  included  in  the  next  section  its  conclusions 
and  recommendations  for  further  development  of  the  TELOS  concept.  These 
conclusions  and  recommendations  are  based  on  its  assessment  of  relative 
importance  in  achieving  the  goal  of  a basic  research  tool  which  can  be 
adapted  to  the  other  roles,  if  DCPA  determines  that  the  roles  need  to  be 
implemented. 


i 


Based  on  the  test  and  conversion  activities  performed  during  Contract 
DCPA01-77-C-0238,  RT I concludes  that: 

« Further  development  of  LEMOS  should  be  carried  out  on  the  UNIVAC 
1100/10  using  its  remote  terminal  facilities. 

• Detailed  documentation,  including  a test  plan,  should  be  prepared 
before  further  testing  is  conducted  or  case  studies  are 
performed. 

• Extension  to  the  TELOS  system,  particularly  the  communications 
submodel,  must  be  undertaken  and  must  be  consistent  with  the 
overall  development  plan  and  evaluation  methodology. 

• The  development  of  the  evaluation  module  methodology  as  outlined 
herein  should  be  started  immediately. 

RTI  recommends  that: 

• Preparation  of  TELOS  documentation  become  the  basis  for 
further  system  development  and  testing. 

» The  program  plan  for  realizing  the  full  potential  be 
val idated. 

• The  next  element  within  LEMOS  to  be  developed  be  the 
communications  submodel. 

• The  methodology  for  local  operating  system  evaluation  using 
the  present  TELOS  structure  be  initiated  with  high  priority. 
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The  descriptions  in  this  Appendix  will  be  identified  by  the  basic  name  in 
the  description  column.  The  following  files  are  described  briefly  in 
subsequent  paragraphs.  Each  of  these  files  are  included  in  Appendix  B except 
for  History,  Performance,  Plot  and  Benefits.  These  files  are  believed  to  be 
inadequate  until  ADS  is  made  compatible  to  the  operations  submodel  by 
resolving  the  issue  as  to  which  submodel  decides  when  the  deaths  occur  for 
casualties. 

® Reference  (REFERENCE) 

• Master  Status  (MSF-2) 

® Problem  (PROBL-3) 

® Resource  (RES) 

« Service  (SERV-2) 

» Operations  (0PS1-2) 

» Assignment  (ASGN1-4) 

o History  (HIST) 

® Performance  (PERF) 

• Plot  (PLOTi-2) 

• Benefits  (BEN) 

• Links  (LINKS) 

o Travel  (TVLREF) 

• Reference  File 

The  Reference  File  contains  a series  of  tables  which  represent  basic 
reference  material  (on  operations,  functions,  and  teams)  required  to  quantify 
the  simulated  operations.  An  Alternative  Table  produces  a set  of  alternative 
operations  given  a specific  problem.  The  Operations  Table  defines  the 
specific  functions  which  constitute  the  operation.  A Function  Table  indicates 
the  teams  which  can  perform  that  function  together  with  their  relative 
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efficiency.  The  characteristics  of  each  team  are  contained  in  the  Team  Table, 
which  along  with  the  Work  Table,  enables  the  user  to  compute  team-hour  and 
resource  requirements  for  functional  performance  to  resolve  problems.  This 
file  may  be  modified  at  the  beginning  of  a simulation,  but  should  not  be 
changed  during  the  time  frame  of  the  scenario. 

• Master  Status  File  (MSF) 

The  Master  Status  File  represents  the  target  model  in  terms  of  area, 
structures,  shelter,  people,  and  other  special  resources.  Each  of  these 
elements  is  classified  by  types  and  status.  Quantities  in  the  MSF  record 
fields  are  changed  in  the  Area  Damage  System  (ADS)  model  to  reflect  target 
degradation.  The  object  of  the  LEMOS  model  is  to  upgrage  resource  states 
using  various  functional  countermeasures,  or  at  least  to  prevent  further 
degradation  by  fire  and  fallout.  This  file  is  a primary  communication  vehicle 
between  ADS  and  LEMOS  and  between  time  periods.  At  the  present  time,  ADS  has 
not  been  modified  to  process  the  special  resources  portion  of  the  MSF. 

• Problem  File  (PROB) 

The  Problem  File  defines  problems  by  unit  area  which  must  be  resolved  by 
the  available  countermeasures.  Four  general  problem  types  are  recognized: 
control,  readiness,  damage,  and  relief  and  rehabilitation.  The  objective  of 
local  operations  is  to  resolve  each  of  these  problems  as  soon  as  practicable. 
o Resource  File  (RES) 

The  Resource  File  quantifies  the  resources  by  unit  area  and  provides  a 
means  for  accounting  for  the  essential  elements  of  the  MSF  during 
countermeasure  processing.  Emphasis  is  placed  on  tracking  personnel  and  CD 
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o Service  File  (SERV) 

The  Service  File  is  required  to  maintain  information  about  the  teams  and 
the  services  to  which  the  team  belony.  It  is  used  in  the  Requirement  Program 
(PGM2)  to  define  readiness  proolems.  The  status  of  each  team  is  determined  in 
the  Operations  Program  (PGM7).  This  represents  a primary  feedback  on  the 
status  of  Civil  Defense  teams. 
o Operations  File  (OPS) 

The  Operations  File  contains  a record  for  each  selected  operation  in 
terms  of  the  specific  functions  needed  to  resolve  the  problem.  In  addition, 
this  record  contains  information  about  quantities,  start  time,  benefits, 
priorities,  and  related  subjects, 
a Assignment  File  (ASGN) 

Each  function  is  represented  by  a record  in  the  Assignment  File  on  which 
the  operation  is  identified,  the  number  of  teams  assigned,  the  start  time 
determined,  and  the  amount  of  effort  expressed  in  team-hours  to  produce  the 
desired  result.  The  operations  and  assignment  are  mixed  within  Program  5 
after  a specific  operation  is  selected. 

Where  movement  of  resources  (including  people  requiring  aid,  or  CD  teams 
and  material  to  provide  aid)  are  required,  trip  records  are  prepared  within 
the  assignment  file  giving  origin  and  destinations  as  well  as  start  and 
arrival  times;  one  trip  record  for  the  unit  area  in  which  the  move 
originates,  and  the  second  for  the  unit  area  in  which  the  move  terminates. 
After  sorting  between  Programs  6 and  7,  these  records  are  used  to  subtract 
resources  from  one  area  to  another  area  to  accomplish  the  deployment. 
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• History  File  (HIST) 

The  assignments  are  executed  in  the  Operations  Program  (PGM7)  by 
expending  resources  and  deriving  benefits.  These  transactions  are  recorded  on 
the  assignment  records  and,  if  desired,  retained  for  historical  analysis.  All 
retained  assignment  records  are  contained  in  the  History  File.  In  most  cases, 
the  History  File  would  not  be  retained. 

• Performance  File  (PERF) 

Data  from  the  Performance  File  is  analyzed  in  the  Report  Generator  and 
tabular  Benefit  and  Readiness  Reports  prepared  in  the  Report  Generation 
Program  (PGM8).  This  program  updates  the  Plot  File. 

• Plot  File  (PLOT) 

Values  of  key  performance  measures  are  retained  from  the  Performance  File 
in  the  Plot  File  for  time  plots  at  designated  breaks  in  the  scenario. 

Normally,  these  breaks  occur  when  interactive  sessions  are  planned  to 
evaluate  intermediate  results  and,  perhaps,  change  priorities,  prohibitions, 
or  limitations  used  to  control  the  scenario. 

» Links  File  (LINKS) 

The  Links  File  contains  information  about  the  highway  system  by  which 
unit  areas  are  linked  and  over  which  resources  are  moved.  The  damage 
assessment  system  does  not  process  this  file  at  the  present  time.  However, 
provision  should  be  made  at  a later  date  to  determine  damage  to  the  highway 
network  (particularly  to  bridges  in  it).  Nevertheless,  some  consideration  is 
given  to  weapons  effects  by  using  the  Basic  Operating  Situation  (BOS) 
designations  from  the  Resource  File. 
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• Travel  Reference  File  (TVLREC) 

The  analysis  of  the  transportation  network  defined  by  the  Links  File  in 
Floyd's  algorithm  leads  to  the  preparation  of  the  Travel  Reference  File 
containing  measures  of  average  travel  time  between  all  origins  and 
destinations  in  terms  of  unit  areas.  These  referece  travel  time  values  are 
used  to  select  assignments  in  the  assignment  subsystem  and  prepare  trip 
records  in  the  Deployment  Program.  Redefinition  of  this  file  depends  on 
changes  in  the  BOS  for  each  unit  area.  However,  it  may  not  be  necessary  to 
re define  it  for  each  time  period  unless  significant  changes  have  occurred 
(e.g.,  another  weapon  detonates  or  severe  environmental  changes  occur  in  many 
unit  areas). 

Specific  formats  for  records  in  these  files  are  contained  in  Appendix  B 
along  with  the  test  data  records  used  to  verify  proper  conversion  at  DCPACC. 
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elements  of  the  ASCII  versions  of  COBOL  and  FORTRAN.  Program  changes  were 
made  and  information  extracted  from  the  compilations  is  given  below  that 
shows  the  successful  completion  of  this  phase  of  the  conversion. 


RESMAIN 

ACOB  4R2  R SL73R1  05/14/79  12:10:20  (18.)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  0 WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 

COMPLETE  TIME  IS  17.60  SECONDS  CORE:  MIN=  54174/54784  MAX=  55296  WORDS 

DCPASORT 

ACOB  4R2  R SL73R1  05/02/79  09:54:45  (19,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  1 WARNING  3 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 

COMPILE  TIME  IS  18.94  SECONDS  CORE:  MIN*  54174/54784  MAX=  54784  WORDS 


NGM1 

ACOB  4R2  R SL73R1  03/28/79  17:10:46  (53,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  4 WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  151.51  SECONDS  CORE:  MIN*  54174/54784  MAX=  55296  WORDS 
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NGM2 

ACOB  4R2  R SL73R1  05/29/79  14:24:55  (31.)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  16  WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  103.82  SECONDS  CORE:  MIN-  54174/54784  MAX=  55808  WORDS 


NGM3  series  (A,  B,  C,  D,  E) 


These  programs,  written  in  IBM/370  FORTRAN  IV,  are,  in  some  cases, 
incompatible  with  ASCII  FORTRAN.  Therefore,  conversion  of  these  programs  was 
not  completed  prior  to  project  termination. 

NGM4 

ACOB  4R2  R SL73R1  05/29/79  14:22:15  (20,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  6 WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  49.72  SECONDS  CORE:  MIN-  54174/54784  MAX-  55296  WORDS 


NGM5 

ACOB  4R2  R SL73R1  04/30/79  11:15:23  (5,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  12  WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  109.35  SECONDS  CORE:  MIN-  54174/54784  MAX=  55296  WORDS 


NGM6 

ACOB  4R2  R SL73R1  05/29/79  16:53:33  (3,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  23  WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  137.14  SECONDS  CORE:  MIN-  54174/54784  MAX=  55808  WORDS 
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NGM7 

ACOB  4R2  R SL73R1  05/01/79  10:58:46  (3,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  11  WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  140.55  SECONDS  CORE:  MIN=  54174/54784  MAX=  55808  WORDS 

NGM8 

ACOB  4R2  R SL73R1  05/14/79  1:50:59  (6,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  14  WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  101.86  SECONDS  CORE:  MIN=  54174/54784  MAX=  55296  WORDS 

NGM9 

ACOB  4R2  R SL73R1  05/14/79  11:53:38  (11,)  1100  ASCII  COBOL  02/06/79  17:46 
(listing) 

END  ACOB  DIAGNOSTIC  TOTALS  12  WARNING  0 MINOR  0 SERIOUS  0 FATAL  0 LEVELING 
COMPILE  TIME  IS  167.68  SECONDS  CORE:  MIN*  54174/54784  MAX=  55296  WORDS 

B.  File  Examples 

After  the  LEMOS  programs  were  compiled,  a number  of  the  resulting 
relocatable  elements  were  mapped  together  to  produce  an  absolute  (executable) 
element.  Using  this  absolute  element,  most  test  files  involved  in  LEMOS  were 
produced,  although  unforeseen  delays  prevented  generation  of  the  History, 
Performance,  Plot,  and  Benefit  Files.  Figures  B-l  through  B-6  present 
partial  listings  of  six  of  the  thirteen  major  LEMOS  files,  which  are  listed 
in  Appendix  A.  Format  descriptions  of  these  files  are  given  in  the  following 
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C.  Master  Status  File 

This  section  contains  t&bles  that  describe  in  detail  the  input  data  and 
their  formats  in  the  Master  Status  File  (MSF).  This  file  is  used  by  both 
TELOS  and  LEMOS  and  thus  forms  the  main  link  between  the  systems.  The  format 
for  the  AREA-RECORD  is  shown  in  Table  B-l,  AREA-RECORD  FORMAT.  One  card  is 
needed  for  each  unit  area.  The  format  for  the  STRUC-DATA  is  shown  in  Table 
B-2,  STRUC-DATA  FORMAT.  One  card  is  needed  for  each  building  type  (Cols. 
20-22)  in  each  land  use  class  present  in  the  unit  area.  The  format  for  the 
SHELTER-DATA  record  is  shown  in  Table  B-3,  SHELTER-DATA  FORMAT.  The  format 
for  the  PERSONNEL-STATUS  Record  is  displayed  in  Table  B-4,  PERSONNEL-STATUS 
FORMAT.  Table  B-5,  SPECIAL-RESOURCES  FORMAT,  give  the  format  for  the 
SPECIAL-RESOURCES  Record.  All  CD  resources  are  described  using  this  format. 

D.  Probl em  File 

Four  general  classes  of  problems  are  encountered  in  this  file.  Each 
class  has  a different  format.  A brief  description  of  the  record  formats  for 
these  four  major  types  of  problems  (i.e..  Control,  Increased  Readiness, 
Damage,  and  Relief)  are  given  in  Tables  B-6  through  B-9.  Records  of  two  or 
more  classes  exist  for  each  land-use  entry  within  a unit  area.  Control  and 
readiness  problems  are  always  present. 

Problems  that  relate  to  the  ability  to  identify,  locate,  direct, 
coordinate,  or  otherwise  control  the  civil  defense  system  are  identified  as 
control  problems.  One  example  is  the  inability  to  inform  people  due  to  the 
disruptions  of  communication  facilities.  The  format  of  the  corresponding 
PROB-TYPE-1  Record  is  shown  in  Table  B-6,  PROB-TYPE-1  FORMAT.  Problems  that 
relate  to  the  vulnerability  of  people  in  a preattack  situation  or  to 
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TABLE  b-1.  AREA-RECORD  FORMAT 


COBOL  Variable 

COBOL 

Format 

Card 

Columns 

Remarks 

CODE-1 

9 

1 

Value  is  1. 

FILLER 

X 

2 

TIME-PERIOD 

9999 

3-  6 

Sequence  number  of  time  period 

FILLER 

X ( 5 ) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

Area  number 

T- INTERVAL 

9(5) 

18-22 

In  minutes 

LAT 

99V999 

23-27 

Latitude 

LON 

999V999 

28-33 

Longitude 

TOTAL-AREA 

9999V99 

34-39 

LUC-PCT 

X(20) 

40-59 

V99  occurs  10  times 

CUR-DOSE-RATE 

9 ( 4 ) V 9 

60-64 

r/hr 

BLAST-RISK-CODE 

9 

65 

FALLOUT-RISK-CODE 

9 

66 

AREA-POP 

9(6) 

67-72 

SHELTER 

9(6) 

73-78 

GEN-STATUS-CODE 

9 

79 

FILLER 

X ( 9 ) 

80-88 

TABLE  B-2.  STRUC-DATA  FORMAT 


COBOL  Variable 

COBOL 

Format 

Card 

Col umns 

Remarks 

CODE-2 

9 

1 

Value  is  2. 

FILLER 

X 

2 

TIME-PERIOD 

9999 

3-  6 

Sequence  number  of  time  period 

FILLER 

X(5) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

ArGu  number 

LUC 

99 

18-19 

Land  Use  Code 

STORIES-CODE 

9 

20 

BLAST-RESIST-CODE 

9 

21 

FIRE-RESIST-CODE 

9 

22 

DAMAGE-CODE 

99 

23-24 

GEN-DEBRIS 

9 

25 

ROUTE-DEBRIS 

9 

26 

NO-UNDAM 

9(6) 

27-32 

NO- STAGE 1 

9(6) 

33-38 

N0-STAGE2 

9(6) 

39-44 

N0-STAGE3 

9(6) 

45-50 

N0-STAGE4 

9(6) 

51-56 

AREA-AFLAME 

99 

57-58 

FILLER 

X(30) 

59-88 

- - : - ■ ' ...... .i. . : j mm., 
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TABLE  B-3.  SHELTER-DATA  FORMAT 


COBOL  Variable 

COBOL 

Format 

Card 

Columns 

Remarks 

CODE-3 

9 

1 

Value  is  3. 

SUBTYPE-CODE 

X 

2 

Value  0 = spaces,  value  1 = people 

TIME-PERIOD 

9999 

3-6 

Sequence  number  of  time  period 

FILLER 

X ( 5 ) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

Area  number 

LUC 

99 

18-19 

STORIES-CODE 

9 

20 

) 

BLAST-RESIST-CODE 

9 

21 

/ Same  as  STRUC-DATA  Record 

FIRE-RESIST-CODE 

9 

22 

) 

TOTAL-SPACES 

9(8) 

23-30 

(Or  people  if  SUBTYPE-CODE  = 1) 

BELOW-PF-DIST 

X(  16) 

31-46 

V99  occurs  8 times 

LOWER-PF-DIST 

X(  16) 

47-62 

V99  occurs  8 times 

UPPER-PF-DIST 

X ( 16 ) 

63-78 

V 99  occurs  8 times 

FILLER 

X(10) 

79-88 

TABLE  B-4.  PERSONNEL-STATUS  RECORD 


COBOL 

Card 

I 

COBOL  Variable 

Format 

Col umns 

Remarks 

CODE-4 

9 

1 

Value  is  4. 

FILLER 

X 

2 

TIME-PERIOD 

9999 

3-6 

Sequence  number  of  time  period 

FILLER 

X(5) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

Area  number 

LUC 

99 

18-19 

STORIES-CODE 

9 

20 

) 

ni  not  n r~  n t r'  *r  nnnr 

D LrtJ  i -P.Lji  J ! U I_ 

r» 

j 

Ol 

v c /-  cTnnr  nnm 

f .inmr  o .)  i i n ncuui  U 

FIRE-RESIST-CODE 

9 

22 

) 

INJURY-CODE 

99 

23-24 

TRAPPED 

9(6) 

25-30 

UNINJ 

9(6) 

31-36 

Those  healed  who  originally  suffered 
type  of  injury  specified  by  INJURY-CODE 

INJ-PHASES: 

X ( 39 ) - 

1 

37-75 

MEAN-TIME 

99V9  | 

1 

1 

MIN-TIME 

99  | 

37-49 

I 

MAX-TIME 

99  i 

50-62 

1 

X ( 1 3 ) occurs  3 times 

CASUALTIES 

9(6) 

63-75 

MEAN-DOSE 

999V9 

76-79 

MIN-DOSE 

999 

80-82 

MAX-DOSE 

999 

83-85 

CD-PCT 

V 999 

86-88 
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TABLE  B-5.  SPECIAL-RESOURCES  FORMAT 


COBOL  Variable 

mu 

Card 
Col  unins 

Remarks 

CODE-5 

9 

1 

Value  is  5. 

SUBTYPE-CODE 

9 

2 

Value  O=non-transient;  value  l=transient 

TIME-PERIOD 

9999 

3-  6 

Sequence  number  of  time  period 

FILLER 

X ( 5 ) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

Area  number 

LUC 

99 

18-19 

FILLER 

XXX 

20-22 

ASSET-CODE 

9 

23 

ASSET-NUMBER 

99 

24-25 

POSTURE 

99 

26-27 

SUPV-COMP 

9 

28 

Value  1 = non-CD;  value  2 = CD 

SUPV-ORGN 

9(8) 

29-36  1 

Not  used 

CONDITION 

9 

37 

EFF-FACTOR 

9V99 

QUANTITY 

9(6) 

41-46 

TRAILING-FIELDS: 

X(32) 

47-88 

Only  for  Asset  Codes  1,  2,  or  3 

(Faci 1 ities ) 

FAC-DAM-CODE 

• 99 

47-48 

FAC-STAT-PCT 

X(25) 

49-73 

9V9999  occurs  5 times 

FAC-DEBRIS 

9 

74 

FILLER 

X ( 14 ) 

75-88 

(Shelter  Spaces) 

; 

SHEL-LVL-CODE 

9 

47 

PF-DIST 

X(16) 

48-65 

99  occurs  9 times 

FILLER 

X(23) 

66-88 

(Personnel ) 

INJ-CODE 

99 

47-48 

TRAPPED-PCT 

9V99 

49-51 

INJ-PHASES: 

MEAN-TIME 

X(30) 

99V9 

52-81 

MIN-TIME 

99 

X ( 10 ) occurs  3 times  (once  for 

MAX-TIME 

INJ-PERC 

99 

9V99 

each  phase) 

MEAN-DOSE 

99V9 

82-84 

M IN-DOSE 

99 

85-86 

In  tens  of  rads 

MAX -DOSE 

99 

87-88 

T 
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TABLE  B-6.  PROB-TYPE-1  FORMAT 


COBOL 

COBOL 

I 

Variable 

Format 

Remarks 

ZONE-1 

999 

AREA-1 

999 

LUC-1 

99 

OLD-NEW 

9 

Defines  old  or  new  record 

CLASS- 1 

9 

Defines  transient  or  non-transient  resources 

PROB-CLASS 

9 

Code  is  "1" 

PROB-SET-1 

99 

FILLER 

X ( 5 ) 

UN-INFO 

X 

1 

UN-PROB 

x 1 

1 

Not  used,  will  be  needed  in 

UN-ENVIRON 

X 1 

communication  submodels. 

RE-PROB 

UN-ASGN-RES 

X ' 

TEAM-1 

9(6) 

SPACES 

9(6) 

CAP-UNITS-1 

9(6) 

Definition  of  capacity  units  vary  from  land 
use  to  land  land  use. 

EQUIP-SETS-1 

9(6) 

RATIONS-1 

9(6) 

WATER- 1 

9(6) 

FUEL-1 

9(6) 

SUP-UNITS-1 

9(6) 

Definition  of  supply  units  vary  from  land 
use  to  land  use. 

TABLE  B-7.  PROB-TYPE-2  FORMAT 


COBOL 

Variable 

| COBOL 
Format  | 

Remarks 

ZONE-1 

AREA-1 

LUC-1 

X(10) 

f 

Same  as  PROB-TYPE-1 

OLD-NEW 

1 

1 

CLASS-1 

1 

PROB-CLASS 

9 

Code  is  2 

PROB-SET-2 

99 

INOP-PERS 

9(6) 

INOP-EQPT 

9(6) 

INOP-VEH 

9(6) 

INOP-FAC 

9(6) 

INOP-SUP 

9(6) 

FAC-DAM 

9(6) 

EQPT-DAM 

9(6) 

SHORTAGE 

9(6) 

UNPRO-PEO 

9(6) 

EQPT-EFF-FACTOR 

9V99 
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Variable 


ON 
AREA-1 
UC 


OLD-NEW 
CLASS-1 
PROB-CLASS 
PROB-SET-3 
NO- FAC -DAM 
FAC-FIRE 
NO-IGN-3 
NO-AFLAME  1-3 
NO-AFLAME  2-3 
NO-BURNED-3 
AREA-ASGN 
NO-FAC-RAD 
NO-FAC-3 
FAC-DEBRIS 
FAC-RAD 
LINK-DEBRIS 
LINK-JAM 
CHG-IND 
FILLER 


Variabl e 


ONE- 1 
AREA-1 
UC-1 
OLD-NEW 
CLASS-1 
PROB-CLASS 
PROB-SET 
QTY-PEOPLE 
PHASE-CODE 
PAS-TYPF 

MEAN-TIME-OF-INJ 
TIME-OF-INJ  (MIN) 
TIME-OF-INJ  (MAX) 
MEAN-CAS-DOSE 
CAS-DOSE  (MIN) 
CAS-DOSE  (MAS) 
CD-CAS-CODE 


TABLE  B-8.  PROB-TYPE-3  FORMAT 


COBOL 

Format 


X(10) 


Same  as  PROB-TYPE-1 


Code  is  3 


V 999 

V 999 

V 999 
V999 

9999V99 

9(6) 

9(6) 

999 

9 ( 5 ) V 99 
999 
9 
X 

X(6) 


TABLE  B-9.  PROB-TYPE-4  FORMAT 


COBOL 

Format 


X(10) 

9 

99 

9(6) 

9 

V 99 
99V9 
99 
99 

999V9 

999 

999 

9 


Same  as  PROB-TYPE-1 


Code  is  4 


Occurs  16  times 





I 


t 

I 
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personnel,  facilities  and  equipment  by  teams  are  readiness  problems.  The 
format  of  the  related  PROB-TYPE-2  Record  is  shown  in  Table  B-7,  PROB-TYPE-2 
FORMAT.  Damage  control  problems,  unlike  other  problem  types,  are  concerned 
with  preventing  the  loss  of  a resource  or  its  utility  rather  than  improving 
an  already  degraded  condition.  Examples  of  this  type  of  problem  include 
firefighting,  decontamination,  and  debris  clearing.  Table  B-8,  PROB-TYPE-3 
FORMAT,  shows  the  format  for  the  corresponding  PROB-TYPE-3  Record.  The 
leading  class  of  problems,  which  relates  directly  to  the  state  of  people, 
consists  of  shelter,  rescue,  treatment,  and  rehabilitation  problems.  It  sets 
the  standard  for  measuring  the  degree  to  which  human  life  has  been  disrupted. 
All  other  problem  groups  must  relate  to  this  one  and  in  this  sense  are 
subordinate  to  it.  The  format  for  such  PROB-TYPE-4  Records  is  given  in 
Table  B-9,  PROB-TYPE-4  FORMAT. 

E.  Other  Example  Files 

Other  files  used  as  examples  in  Figures  B-l  through  B-6  include  the 
Resource  File,  the  Service  File,  the  Operations  File,  and  the  Assignment 
File,  the  formats  of  which  are  shown,  respectively,  in  Tables  B-IO  through 
B— 13  - 


I 
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TABLE  B-10.  RESOURCE  DATA  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

PART-1 

ZONE-ID-2 

X (3 ) 

AREA-ID-2 

X ( 3 ) 

LUC-CODE-2 

99 

FILLER 

X 

CLASS-2 

9 

ENVIRON-CLASS 

9 

PART-2 

PART-2A 

BOS 

9 

TOTAL-AREA-2 

999V99 

NO-STRUC 

9(6) 

TOTAL-TOTAL 

9(6) 

CD-FORCE 

9(6) 

TOTAL-UNINJ 

9(6) 

RESOURCES 

RESOURCE 

9(6) 

Occurs  8 times 

REFUGEES 

9(6) 

PROB-CD 

9(6) 

PROB-NCD 

9(6) 

TOTAL-DEAD-1 

9(6) 

CD-DEAD 

9(6) 

CD-POSTURE 

99 

AVG-UNINJ-DOSE(NCD) 

999V9 

AVG-UNINJ-DOSE(CD) 

999V9 

1 
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TABLE  B-ll . SERV-RECORD  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

ADDRESS-11 

ORGN-11 

ZONE-11 

99 

EOC-11 

99 

GROUP-11 

99 

SECTION-11 

99 

SERVICE-11 

99 

AREA-ID-11 

X ( 6 ) 

TEAM-ID-11 

99 

NO-TEAMS-11 

9(6) 

FUNC-DIST 

PCT-BY-FUNC 

V999 

Occurs  8 times. 

STATE-DISTRB 

PCT-BY-STATE 

V999 

Occurs  8 times. 

NO-FUNC-11 

99 

TEAMS-FORCE 

9(5)V9 

TEAMS-LOST 

9(5)V9 

SUM-RES 

RES-SUM 

9(6) 

Occurs  8 times. 
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TABLE  B-13.  ASGN-DATA  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

CUR-ADRS 

CUR-ZONE 

XXX 

CUR-UA 

999 

CUR-LUC 

99 

DEST-ADDRS 

ZONE-4 

99 

EOC-4 

99 

GRP-4 

99 

SEC-4 

99 

OPN-4 

OPN-4-1 

ORGIN-4 

X ( 6 ) 

LUC-4 

99 

SEQ-4 

99 

TYPE-4 

9 

CODE-4 

99 

ALT-4 

9 

SEQ-4A 

9 

MOBILITY-CODE 

9 

TEAM-4 

99 

ORGN-4 

ZONE 

99 

EOC 

99 

GRP 

99 

SEC 

99 

SERVICE-4 

99 

RES-ASGN 

9(6) 

Occurs  8 times. 

ASGN-QTY 

9(6) 

FUNC-NO-4 

99 

TIME-IN-FUNC 

9(3)V9 

START-TIME 

9(3)V9 

ARRIVAL-TIME 

9(3)V9 

COMPLETION-TIME-EST 

9 ( 3 ) V 9 

COMPLETION-TIME-ACT 

9(3)V9 

THR-M 

9(3)V9 

THR-I 

9(3)V9 

THR-R 

9(3)V9 

THR-0 

9 ( 3 ) V 9 

PREP-THR 

9(3)V9 

PROD-THR 

9(3)V9 

BEN-CODE 

XX 

NO-POT-BEN 

9(6) 

IP-4 

99V9 

SP-4 

V9999 

SP-41 

V9999 
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TABLE  B-13.  ASGN-DATA  FORMAT  (Continued) 


COBOL 

Variable 

COBOL 

Format 

Remarks 

SP-42 

V9999 

SP-43 

V 9999 

SP-44 

V9999 

NO-ASGN 

999 

FP-4 

99 

AREA-ADRS2 

ZONE-ADRS 

999 

AREA-ADRS3 

999 

FILLER 

X ( 38 ) 

LOCATION-3 

L0C3-Z0NE 

99 

L0C3-E0C 

99 

L0C3-GRP 

99 

LOC3-SEC 

99 

AREA-3 

AREA3-ZONE 

999 

AREA3-ADRS 

999 

REC-C0DE13 

X 

REC-C0DE23 

9 
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